[Buildroot] microperl fixes and improvements

[Buildroot] microperl fixes and improvements

[Gustavo Zacarias]

As Peter noted on IRC libxml-parser-perl and intltool have issues with
the microperl package conversion and bump.

The first problem is hardcoded PERLLIB paths.
This is no longer necessary and actually harmful.

Also implemented a new library search path tweak that SHOULD fix building
on newer ubuntu distributions which use non-conventional library paths.

TODO:

* Rename libxml-parser-perl closer to it's real name XML::Parser
  We can wait until we do more modules since it's host-only for now.

* Make target microperl optionally a fully-fledged perl
  Needs an architecture cache implementation.

* Start adding other useful modules from CPAN

[Buildroot] [PATCH 1/3] intltool: no business defining PERLLIB

[Gustavo Zacarias]

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
 package/intltool/intltool.mk |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/package/intltool/intltool.mk b/package/intltool/intltool.mk
index 6d13cc1..1e749ea 100644
--- a/package/intltool/intltool.mk
+++ b/package/intltool/intltool.mk
@@ -9,8 +9,6 @@ INTLTOOL_SOURCE = intltool-$(INTLTOOL_VERSION).tar.bz2
 INTLTOOL_SITE = http://ftp.acc.umu.se/pub/GNOME/sources/intltool/0.40/
 
 HOST_INTLTOOL_DEPENDENCIES = host-libxml-parser-perl
-HOST_INTLTOOL_CONF_OPT = \
-  PERLLIB=$(HOST_DIR)/usr/lib/perl
 
 $(eval $(call AUTOTARGETS))
 $(eval $(call AUTOTARGETS,host))
-- 
1.7.3.4

[Buildroot] [PATCH 2/3] libxml-parser-perl: add missing dep and drop wrong paths

[Gustavo Zacarias]

Drop incorrect INSTALL* paths, host-microperl knows better.
Also need host-microperl dependency before building.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
 package/libxml-parser-perl/libxml-parser-perl.mk |   18 +++++++-----------
 1 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/package/libxml-parser-perl/libxml-parser-perl.mk b/package/libxml-parser-perl/libxml-parser-perl.mk
index 9e6f2ec..0bcda5d 100644
--- a/package/libxml-parser-perl/libxml-parser-perl.mk
+++ b/package/libxml-parser-perl/libxml-parser-perl.mk
@@ -3,32 +3,28 @@
 # libxml-parser-perl
 #
 #############################################################
-LIBXML_PARSER_PERL_VERSION:=2.36
-LIBXML_PARSER_PERL_SOURCE:=XML-Parser-$(LIBXML_PARSER_PERL_VERSION).tar.gz
-LIBXML_PARSER_PERL_SITE:=http://www.cpan.org/modules/by-module/XML/
 
-LIBXML_PARSER_PERL_DEPENDENCIES = expat
+LIBXML_PARSER_PERL_VERSION = 2.36
+LIBXML_PARSER_PERL_SOURCE = XML-Parser-$(LIBXML_PARSER_PERL_VERSION).tar.gz
+LIBXML_PARSER_PERL_SITE = http://www.cpan.org/modules/by-module/XML/
+LIBXML_PARSER_PERL_DEPENDENCIES = expat host-microperl
 
 define HOST_LIBXML_PARSER_PERL_CONFIGURE_CMDS
  (cd $(@D) ; \
-   perl Makefile.PL \
+   $(HOST_DIR)/usr/bin/perl Makefile.PL \
         PREFIX=$(HOST_DIR)/usr \
         EXPATLIBPATH=$(HOST_DIR)/usr/lib \
         EXPATINCPATH=$(HOST_DIR)/usr/include \
-        INSTALLDIRS=site \
-        INSTALLSITELIB=$(HOST_DIR)/usr/lib/perl \
-        INSTALLSITEARCH=$(HOST_DIR)/usr/lib/perl \
  )
 endef
 
 define HOST_LIBXML_PARSER_PERL_BUILD_CMDS
- $(HOST_MAKE_ENV) $(MAKE) -C $(@D)
+	$(HOST_MAKE_ENV) $(MAKE) -C $(@D)
 endef
 
 define HOST_LIBXML_PARSER_PERL_INSTALL_CMDS
- $(HOST_MAKE_ENV) $(MAKE) -C $(@D) install
+	$(HOST_MAKE_ENV) $(MAKE) -C $(@D) install
 endef
 
 $(eval $(call GENTARGETS))
 $(eval $(call GENTARGETS,host))
-
-- 
1.7.3.4

[Buildroot] [PATCH 3/3] host-microperl: define module paths and other improvements

[Gustavo Zacarias]

Define archlib, privlib, sitelib and sitearch for host-microperl so that
modules get installed in a unified directory hierarchy.

Drop loclibpth and switch to libpth using the host linker to dump all
the library search paths. This should fix ubuntu build issues.

Switch from -des to -der to make the detection phase faster.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
 package/microperl/microperl.mk |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/package/microperl/microperl.mk b/package/microperl/microperl.mk
index d5b5a7c..74d7046 100644
--- a/package/microperl/microperl.mk
+++ b/package/microperl/microperl.mk
@@ -26,7 +26,12 @@ endif
 define HOST_MICROPERL_CONFIGURE_CMDS
 	cd $(@D) ; \
 	./Configure -Dcc="$(HOSTCC)" -Dprefix="$(HOST_DIR)/usr" \
-		-Dloclibpth='/lib /lib64 /usr/lib /usr/lib64' -des
+		-Darchlib="$(HOST_DIR)/usr/lib/perl5/$(MICROPERL_VERSION)/`uname -m`" \
+		-Dprivlib="$(HOST_DIR)/usr/lib/perl5/$(MICROPERL_VERSION)" \
+		-Dsitelib="$(HOST_DIR)/usr/lib/perl5/site_perl/$(MICROPERL_VERSION)" \
+		-Dsitearch="$(HOST_DIR)/usr/lib/perl5/site_perl/$(MICROPERL_VERSION)/`uname -m`" \
+		-Dlibpth="`ld --verbose|grep SEARCH_DIR|sed -e 's/SEARCH_DIR("//g' -e 's/");//g'`" \
+		-der
 endef
 
 define HOST_MICROPERL_BUILD_CMDS
-- 
1.7.3.4

[Buildroot] [PATCH 1/3] intltool: no business defining PERLLIB

[Thomas Petazzoni]

Hello,

Le Sun, 11 Mar 2012 22:58:49 -0300,
Gustavo Zacarias <gustavo@zacarias.com.ar> a ?crit :

>  HOST_INTLTOOL_DEPENDENCIES = host-libxml-parser-perl
> -HOST_INTLTOOL_CONF_OPT = \
> -  PERLLIB=$(HOST_DIR)/usr/lib/perl

Has this been tested on a system where libxml-parser-perl is not
installed?

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 1/3] intltool: no business defining PERLLIB

[Thomas Petazzoni]

Le Sun, 11 Mar 2012 22:58:49 -0300,
Gustavo Zacarias <gustavo@zacarias.com.ar> a ?crit :

>  $(eval $(call AUTOTARGETS))

This could be removed. We don't have libxml-parser-perl for the target.
This line used to be necessary because the host variant wouldn't work
without the target variant being defined, but it's no longer the case.
Therefore, the package/intltool/Config.in could go as well.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 2/3] libxml-parser-perl: add missing dep and drop wrong paths

[Thomas Petazzoni]

Le Sun, 11 Mar 2012 22:58:50 -0300,
Gustavo Zacarias <gustavo@zacarias.com.ar> a ?crit :

>  $(eval $(call GENTARGETS))

Same thing here: we don't need this anymore, since we don't support
building libxml-parser-perl for the target. And the
package/libxml-parser-perl/Config.in could go away as well.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 2/3] libxml-parser-perl: add missing dep and drop wrong paths

[Thomas Petazzoni]

Hello,

Le Sun, 11 Mar 2012 22:58:50 -0300,
Gustavo Zacarias <gustavo@zacarias.com.ar> a ?crit :

> -LIBXML_PARSER_PERL_DEPENDENCIES = expat
> +LIBXML_PARSER_PERL_VERSION = 2.36
> +LIBXML_PARSER_PERL_SOURCE =
> XML-Parser-$(LIBXML_PARSER_PERL_VERSION).tar.gz
> +LIBXML_PARSER_PERL_SITE = http://www.cpan.org/modules/by-module/XML/
> +LIBXML_PARSER_PERL_DEPENDENCIES = expat host-microperl 
>  define HOST_LIBXML_PARSER_PERL_CONFIGURE_CMDS
>   (cd $(@D) ; \
> -   perl Makefile.PL \
> +   $(HOST_DIR)/usr/bin/perl Makefile.PL \

Unless there is a strong reason to do, I would prefer this change not
to go in. Buildroot has Perl amongst its mandatory dependencies
(see support/dependencies/dependencies.sh), so I'd prefer if we used
the Perl interpreter available on the host machine rather than building
our own. This will add quite a bit of build time, that apparently we
can avoid since we have been doing that for quite some time now.

Is there a good reason to switch to our own Perl built for the host?

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 2/3] libxml-parser-perl: add missing dep and drop wrong paths

[Gustavo Zacarias]

On 2012-03-12 04:01, Thomas Petazzoni wrote:

> Le Sun, 11 Mar 2012 22:58:50 -0300,
> Gustavo Zacarias <gustavo@zacarias.com.ar> a ?crit :
>
>>  $(eval $(call GENTARGETS))
>
> Same thing here: we don't need this anymore, since we don't support
> building libxml-parser-perl for the target. And the
> package/libxml-parser-perl/Config.in could go away as well.
>
> Thomas

I was just trying to address the issue Peter found, not clean them up 
at the same time, but yeah, they could be dropped.
Regards.

[Buildroot] [PATCH 2/3] libxml-parser-perl: add missing dep and drop wrong paths

[Gustavo Zacarias]

On 2012-03-12 04:46, Thomas Petazzoni wrote:

> Hello,
>
> Le Sun, 11 Mar 2012 22:58:50 -0300,
> Gustavo Zacarias <gustavo@zacarias.com.ar> a ?crit :
>
>> -LIBXML_PARSER_PERL_DEPENDENCIES = expat
>> +LIBXML_PARSER_PERL_VERSION = 2.36
>> +LIBXML_PARSER_PERL_SOURCE =
>> XML-Parser-$(LIBXML_PARSER_PERL_VERSION).tar.gz
>> +LIBXML_PARSER_PERL_SITE = 
>> http://www.cpan.org/modules/by-module/XML/
>> +LIBXML_PARSER_PERL_DEPENDENCIES = expat host-microperl
>>  define HOST_LIBXML_PARSER_PERL_CONFIGURE_CMDS
>>   (cd $(@D) ; \
>> -   perl Makefile.PL \
>> +   $(HOST_DIR)/usr/bin/perl Makefile.PL \
>
> Unless there is a strong reason to do, I would prefer this change not
> to go in. Buildroot has Perl amongst its mandatory dependencies
> (see support/dependencies/dependencies.sh), so I'd prefer if we used
> the Perl interpreter available on the host machine rather than 
> building
> our own. This will add quite a bit of build time, that apparently we
> can avoid since we have been doing that for quite some time now.
>
> Is there a good reason to switch to our own Perl built for the host?
>
> Best regards,
>
> Thomas

The big issue right now is that the new host-microperl installs a real 
perl in $(HOST_DIR)/usr/bin and PATH precedence makes it win over any 
other perl installed on the system.
So there are two solutions, either rename it to some other thing or 
make it work as a host tool.
The solution i approached was making it work as host with the patches 
i've sent.
Otherwise renaming it would be somewhat simple and we could just kill 
the libxml-parser-perl package since it has no reason to exist being 
host-only.
Most of the packages that require intltool are somewhat big in 
dependencies and build time anyway (pulseaudio, gtk2-engines, 
x11r7/xkeyboard-config, gmpc, midori) with the exception of 
shared-mime-info and avahi.
As for reasons, other than dropping the distro-installed perl 
dependency and, in the future when/if we get CPAN modules we'd have a 
conflict of distro module vs. host (as in host package) module given the 
original purpose of libxml-parser-perl if we wanted to implement 
some/all host-variant modules for some future reason.
Also libxml-parser-perl should be named something closer to the 
upstream name XML::Parser
Regards.

[Buildroot] [PATCH 1/3] intltool: no business defining PERLLIB

[Gustavo Zacarias]

On 2012-03-12 03:58, Thomas Petazzoni wrote:

> Hello,
>
> Le Sun, 11 Mar 2012 22:58:49 -0300,
> Gustavo Zacarias <gustavo@zacarias.com.ar> a ?crit :
>
>>  HOST_INTLTOOL_DEPENDENCIES = host-libxml-parser-perl
>> -HOST_INTLTOOL_CONF_OPT = \
>> -  PERLLIB=$(HOST_DIR)/usr/lib/perl
>
> Has this been tested on a system where libxml-parser-perl is not
> installed?
>
> Thomas

That's easy to reproduce and yes, did so by doing "mv /usr/lib/perl5 
/usr/lib/perl5.oops"
As long as your distro uses /usr/lib/perl5 and not /usr/lib/perl or 
some other directory of course, but the same thing applies anyway.
Regards.

[Buildroot] [PATCH 2/3] libxml-parser-perl: add missing dep and drop wrong paths

[Thomas Petazzoni]

Hello,

Le Mon, 12 Mar 2012 07:07:33 -0300,
Gustavo Zacarias <gustavo@zacarias.com.ar> a ?crit :

> The big issue right now is that the new host-microperl installs a
> real perl in $(HOST_DIR)/usr/bin and PATH precedence makes it win
> over any other perl installed on the system.

Right, but the question brings us back to why do we need to build a
host-microperl at all? Perl is part of our hard dependencies, so why
would we need to build it for the host?

The reason why we build XML::Parser is that it is not necessarily
installed on the host (for example it is not part of the default Debian
installation, while the Perl interpreter is). And we can perfectly
build XML::Parser and install it in $(HOST_DIR), and still use the Perl
interpreter provided by the distribution.

> So there are two solutions, either rename it to some other thing or 
> make it work as a host tool.

And not build Perl for the host and use the one of the system?

> The solution i approached was making it work as host with the patches 
> i've sent.
> Otherwise renaming it would be somewhat simple and we could just kill 
> the libxml-parser-perl package since it has no reason to exist being 
> host-only.

It has a reason to exist host-only: XML::Parser is not necessarily
present on the system of the user.

I am the one who created this package, and it was on purpose: it was
necessary to be able to build host-intltool without having to add a new
hard dependency in support/dependencies/dependencies.sh on XML::Parser.

At the moment, I only see drawbacks in switching from the current
solution to building host-microperl. Could you explain why you think
building host-microperl is better?

> Most of the packages that require intltool are somewhat big in 
> dependencies and build time anyway (pulseaudio, gtk2-engines, 
> x11r7/xkeyboard-config, gmpc, midori) with the exception of 
> shared-mime-info and avahi.

Sure, but it's still a new thing that gets built while it already
exists on the host system.

> As for reasons, other than dropping the distro-installed perl 
> dependency and,

It's part of the default install of most distros, so that's really not
a really problematic dependency.

> in the future when/if we get CPAN modules we'd have a 
> conflict of distro module vs. host (as in host package) module given
> the original purpose of libxml-parser-perl if we wanted to implement 
> some/all host-variant modules for some future reason.

We handle this problem very well for normal C/C++ libraries (having our
own version in $(HOST_DIR)/usr/lib, while a different version might be
in /usr/lib), and I don't see now why it wouldn't be possible to do the
same for Perl modules.

> Also libxml-parser-perl should be named something closer to the 
> upstream name XML::Parser

Well:

    XML::Parser
 libxml- parser-perl

Isn't that close enough? Of course, could be perl-xml-parser, but I'm
not sure it makes such a big difference. But I have no strong opinion
on this specific thing.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 1/3] intltool: no business defining PERLLIB

[Thomas Petazzoni]

Hello,

Le Mon, 12 Mar 2012 07:14:51 -0300,
Gustavo Zacarias <gustavo@zacarias.com.ar> a ?crit :

> >>  HOST_INTLTOOL_DEPENDENCIES = host-libxml-parser-perl
> >> -HOST_INTLTOOL_CONF_OPT = \
> >> -  PERLLIB=$(HOST_DIR)/usr/lib/perl
> >
> > Has this been tested on a system where libxml-parser-perl is not
> > installed?
> >
> > Thomas
> 
> That's easy to reproduce and yes, did so by doing "mv /usr/lib/perl5 
> /usr/lib/perl5.oops"
> As long as your distro uses /usr/lib/perl5 and not /usr/lib/perl or 
> some other directory of course, but the same thing applies anyway.

Yes, of course, I missed the fact that you were using a host-microperl,
which I guess it built to look in $(HOST_DIR)/usr/lib/perl by default.
This PERLLIB option is needed if you want to use the Perl provided by
the distro, and you need it to look into this specific place for Perl
modules.

As said in my other mail, I am not convinced we need host-microperl.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 2/3] libxml-parser-perl: add missing dep and drop wrong paths

[Gustavo Zacarias]

On 2012-03-12 08:31, Thomas Petazzoni wrote:

> Right, but the question brings us back to why do we need to build a
> host-microperl at all? Perl is part of our hard dependencies, so why
> would we need to build it for the host?
>
> The reason why we build XML::Parser is that it is not necessarily
> installed on the host (for example it is not part of the default 
> Debian
> installation, while the Perl interpreter is). And we can perfectly
> build XML::Parser and install it in $(HOST_DIR), and still use the 
> Perl
> interpreter provided by the distribution.

We need host-(micro)perl for target perl/microperl, otherwise you can't 
build any modules.
And you can't have a version mismatch, that just calls for a world of 
pain, so you can't trust distro-perl for that.
Otherwise it would be "please install perl 5.12.4 in your distro" which 
would be a big no-no.

>> So there are two solutions, either rename it to some other thing or
>> make it work as a host tool.
>
> And not build Perl for the host and use the one of the system?

Reason above.
Otherwise we can't support target microperl with any module, not even 
Config.pm.
Try building a target perl and removing /usr/lib/perl5, that's the 
result.
No Config.pm, no default INCPATH or other usually well-defined things.

> It has a reason to exist host-only: XML::Parser is not necessarily
> present on the system of the user.
>
> I am the one who created this package, and it was on purpose: it was
> necessary to be able to build host-intltool without having to add a 
> new
> hard dependency in support/dependencies/dependencies.sh on 
> XML::Parser.
>
> At the moment, I only see drawbacks in switching from the current
> solution to building host-microperl. Could you explain why you think
> building host-microperl is better?

CPAN modules in the future, and basic expected behaviour for target 
perl right now.

> We handle this problem very well for normal C/C++ libraries (having 
> our
> own version in $(HOST_DIR)/usr/lib, while a different version might 
> be
> in /usr/lib), and I don't see now why it wouldn't be possible to do 
> the
> same for Perl modules.

XS modules are basically shared objects (always) + interpreted perl 
code (sometimes), and there's no guarantee ABI won't break between major 
perl versions.

> Isn't that close enough? Of course, could be perl-xml-parser, but I'm
> not sure it makes such a big difference. But I have no strong opinion
> on this specific thing.

It's just maintaining consistency, no rush in changing it, it's just 
the debian name at use right now, which IMHO is wrong since it doesn't 
use libxml (actually it uses expat) and thus confusing somehow.
And there's also another (*) libxml-perl to makes thing worse :)
* http://perl-xml.sourceforge.net/libxml-perl/

Regards.

[Buildroot] [PATCH 1/3] intltool: no business defining PERLLIB

[Gustavo Zacarias]

On 2012-03-12 08:33, Thomas Petazzoni wrote:

> Yes, of course, I missed the fact that you were using a 
> host-microperl,
> which I guess it built to look in $(HOST_DIR)/usr/lib/perl by 
> default.
> This PERLLIB option is needed if you want to use the Perl provided by
> the distro, and you need it to look into this specific place for Perl
> modules.
>
> As said in my other mail, I am not convinced we need host-microperl.

I'm aware of what PERLLIB does.
It's just a matter of which path to choose, if we ditch 
host-(micro)perl we loose all ability to build target modules in a sane 
way.
Also it's not that host-(micro)perl is built every time someone builds 
any package, it's just used for intltool which usually implies a 
medium/big target project, and perl doesn't take that long to build on 
modern hardware.
The other intermediate solution is to make $(HOST_DIR)/usr/bin/perl 
$(HOST_DIR)/usr/bin/host-perl and make the libxml-perl-parser module a 
bizarre contraption that means host-perl -> distro-perl since the host 
variant will not work with host-(micro)perl in many scenarios.
IMHO not so nice, that's just my $.01
Regards.

[Buildroot] [PATCH 1/3] intltool: no business defining PERLLIB

[Thomas Petazzoni]

Le Sun, 11 Mar 2012 22:58:49 -0300,
Gustavo Zacarias <gustavo@zacarias.com.ar> a ?crit :

> Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
> ---
>  package/intltool/intltool.mk |    2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)
> 
> diff --git a/package/intltool/intltool.mk b/package/intltool/intltool.mk
> index 6d13cc1..1e749ea 100644
> --- a/package/intltool/intltool.mk
> +++ b/package/intltool/intltool.mk
> @@ -9,8 +9,6 @@ INTLTOOL_SOURCE = intltool-$(INTLTOOL_VERSION).tar.bz2
>  INTLTOOL_SITE = http://ftp.acc.umu.se/pub/GNOME/sources/intltool/0.40/
>  
>  HOST_INTLTOOL_DEPENDENCIES = host-libxml-parser-perl
> -HOST_INTLTOOL_CONF_OPT = \
> -  PERLLIB=$(HOST_DIR)/usr/lib/perl

I am sorry, but after testing this, the build definitely fails on
machines that have just a Perl interpreter installed (and the
XML::Parser Perl module not installed).

See:

make[1]: Leaving directory `/home/test/test/output/build/host-libxml-parser-perl-2.36'
^[[3m>>> host-intltool 0.40.6 Configuring^[[23m
(cd /home/test/test/output/build/host-intltool-0.40.6/ && rm -rf config.cache; PATH=/home/test/test/output/host/bin:/home/test/test/output/host/usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/games AR="/usr/bin/ar" AS="/usr/bin/as" LD="/usr/bin/ld" NM="/usr/bin/nm" CC="/usr/bin/gcc" GCC="/usr/bin/gcc" CXX="/usr/bin/g++" CPP="/usr/bin/cpp" CFLAGS="-O2 -I/home/test/test/output/host/include -I/home/test/test/output/host/usr/include" CXXFLAGS="-I/home/test/test/output/host/include -I/home/test/test/output/host/usr/include" LDFLAGS="-L/home/test/test/output/host/lib -L/home/test/test/output/host/usr/lib -Wl,-rpath,/home/test/test/output/host/usr/lib" PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1 PKG_CONFIG_ALLOW_SYSTEM_LIBS=1 PKG_CONFIG="/home/test/test/output/host/usr/bin/pkg-config" PKG_CONFIG_SYSROOT_DIR="/" PKG_CONFIG_LIBDIR="/home/test/test/output/host/usr/lib/pkgconfig:/home/test/test/output/host/usr/share/pkgconfig" PERLLIB="/home/test/test/output/host/usr/lib/perl" LD_LIBRARY_PATH="/home/test/test/output/host/usr/lib:" CFLAGS="-O2 -I/home/test/test/output/host/include -I/home/test/test/output/host/usr/include" LDFLAGS="-L/home/test/test/output/host/lib -L/home/test/test/output/host/usr/lib -Wl,-rpath,/home/test/test/output/host/usr/lib"  ./configure --prefix="/home/test/test/output/host/usr" --sysconfdir="/home/test/test/output/host/etc" --enable-shared --disable-static PERLLIB=/home/test/test/output/host/usr/lib/perl )
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking for perl... /home/test/test/output/host/usr/bin/perl
checking for perl >= 5.8.1... 5.12.4
checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool
make: *** [/home/test/test/output/build/host-intltool-0.40.6/.stamp_configured] Error 1

So this commit should be reverted, in my opinion, unless host-microperl
becomes a dependency of host-intltool which I am not really in favor of.

Best regards,

Thomas Petazzoni
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 1/3] intltool: no business defining PERLLIB

[Gustavo Zacarias]

On 2012-03-19 12:30, Thomas Petazzoni wrote:

> Le Sun, 11 Mar 2012 22:58:49 -0300,
> Gustavo Zacarias <gustavo@zacarias.com.ar> a ?crit :
>
>> Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
>> ---
>>  package/intltool/intltool.mk |    2 --
>>  1 files changed, 0 insertions(+), 2 deletions(-)
>>
>> diff --git a/package/intltool/intltool.mk 
>> b/package/intltool/intltool.mk
>> index 6d13cc1..1e749ea 100644
>> --- a/package/intltool/intltool.mk
>> +++ b/package/intltool/intltool.mk
>> @@ -9,8 +9,6 @@ INTLTOOL_SOURCE = 
>> intltool-$(INTLTOOL_VERSION).tar.bz2
>>  INTLTOOL_SITE = 
>> http://ftp.acc.umu.se/pub/GNOME/sources/intltool/0.40/
>>
>>  HOST_INTLTOOL_DEPENDENCIES = host-libxml-parser-perl
>> -HOST_INTLTOOL_CONF_OPT = \
>> -  PERLLIB=$(HOST_DIR)/usr/lib/perl
> So this commit should be reverted, in my opinion, unless 
> host-microperl
> becomes a dependency of host-intltool which I am not really in favor 
> of.
>
> Best regards,
>
> Thomas Petazzoni

Reverted? It was never applied.
We've already discussed this on IRC and i stand on my position about 
it.
A cold host-microperl build takes roughly 2 minutes on my quite mundane 
desktop with it's slow hard drive.
So please someone else(s) fix it as they see fit, i'm not submitting 
anything else perl-related.
Future-proof doesn't seem to be the rule which is what i aimed at so 
i'll just quit doing anything perl-related which was mostly as a favour 
since i don't use it even though i code in perl for other purposes.
Regards.

[Buildroot] [PATCH 1/3] intltool: no business defining PERLLIB

[Thomas Petazzoni]

Le Mon, 19 Mar 2012 12:52:04 -0300,
Gustavo Zacarias <gustavo@zacarias.com.ar> a ?crit :

> Reverted? It was never applied.

Sorry, my bad, I thought it had been applied and was the reason of the
failure. I will investigate what is causing this new breakage.

> We've already discussed this on IRC and i stand on my position about 
> it.
> A cold host-microperl build takes roughly 2 minutes on my quite mundane 
> desktop with it's slow hard drive.
> So please someone else(s) fix it as they see fit, i'm not submitting 
> anything else perl-related.
> Future-proof doesn't seem to be the rule which is what i aimed at so 
> i'll just quit doing anything perl-related which was mostly as a favour 
> since i don't use it even though i code in perl for other purposes.

Gustavo, your work on Perl is really appreciated, but I think it's also
fair to have a discussion on the pros and cons of various changes.

I am completely in favor of a solution where host-microperl gets built
when microperl for the target is selected since as you say, it is the
only solution to reliably build XS Perl modules for the target.

However, I wanted us to *investigate* the potential solutions to build
host-microperl *only* when microperl for the target is selected, and
not when we need a simple random utility such as intltool running on
the host.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 1/3] intltool: no business defining PERLLIB

[Gustavo Zacarias]

On 2012-03-19 12:57, Thomas Petazzoni wrote:

> Gustavo, your work on Perl is really appreciated, but I think it's 
> also
> fair to have a discussion on the pros and cons of various changes.
>
> I am completely in favor of a solution where host-microperl gets 
> built
> when microperl for the target is selected since as you say, it is the
> only solution to reliably build XS Perl modules for the target.
>
> However, I wanted us to *investigate* the potential solutions to 
> build
> host-microperl *only* when microperl for the target is selected, and
> not when we need a simple random utility such as intltool running on
> the host.
>
> Thomas

If someone wants perl modules/bindings for some package, and said 
package just accepts --with/without-perl and just searchs the PATH for 
perl, what would you do? (which is a pretty common scenario for non-CPAN 
stuff)
Renaming otherperl back to perl back and forth for this kind of 
packages? Changing the PATH for configure/make?
And most don't accept a --with-perl=otherperl syntax.
The solution is simple, rename it to some other thing, but you'll loose 
the possibility of many bindings/modules for packages, it's quite simple 
actually.
I won't submit a patch to do that though since i'm against the idea.
Regards.

[Buildroot] [PATCH 1/3] intltool: no business defining PERLLIB

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 Thomas> Le Mon, 19 Mar 2012 12:52:04 -0300,
 Thomas> Gustavo Zacarias <gustavo@zacarias.com.ar> a ?crit :

 >> Reverted? It was never applied.

 Thomas> Sorry, my bad, I thought it had been applied and was the reason of the
 Thomas> failure. I will investigate what is causing this new breakage.

It was afaik the microperl -> gentargets change.

 Thomas> However, I wanted us to *investigate* the potential solutions
 Thomas> to build host-microperl *only* when microperl for the target is
 Thomas> selected, and not when we need a simple random utility such as
 Thomas> intltool running on the host.

Yes, let's find a nice solution. Both your inputs are very much
appreciated. Gustavoz, I haven't had time to look at your fixup patches
yet, but will do so very soon.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 1/3] intltool: no business defining PERLLIB

[Thomas Petazzoni]

Le Mon, 19 Mar 2012 17:22:00 +0100,
Peter Korsgaard <jacmet@uclibc.org> a ?crit :

>  >> Reverted? It was never applied.
> 
>  Thomas> Sorry, my bad, I thought it had been applied and was the reason of the
>  Thomas> failure. I will investigate what is causing this new breakage.
> 
> It was afaik the microperl -> gentargets change.

Ah, yes, on the failed cases, I have BR2_PACKAGE_MICROPERL=y.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com