Skip to contentSkip to conversation

microperl fixes and improvements

Buildroot New Gustavo Zacarias 3 participants 21 messages Mar 12, 2012 – Mar 19, 2012

lore
Share & tools
lore

Gustavo Zacarias

author
#0 lore raw

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

author
#1 lore raw

PATCH 1/3 intltool: no business defining PERLLIB

Signed-off-by Gustavo Zacarias <[email protected]>
---
 package/intltool/intltool.mk |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)
package/intltool/intltool.mk +0 -2
index 6d13cc1..1e749ea 100644
@@ -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))
Signature · 1 line
1.7.3.4
#2 lore raw

PATCH 1/3 intltool: no business defining PERLLIB

Hello,

Le Sun, 11 Mar 2012 22:58:49 -0300,
Gustavo Zacarias <[email protected]> a ?crit :

package/intltool/intltool.mk INTLTOOL_SOURCE = intltool-$(INTLTOOL_VERSION).tar.bz2 · line 13

Quoted 3 lines

HOST_INTLTOOL_DEPENDENCIES = host-libxml-parser-perl

package/intltool/intltool.mk +0 -2
-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

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
author
#3 lore raw

PATCH 1/3 intltool: no business defining PERLLIB

Quoted 5 lines · Thomas Petazzoni

Hello,

Le Sun, 11 Mar 2012 22:58:49 -0300,
Gustavo Zacarias <[email protected]> a ?crit :

Quoted 8 lines

package/intltool/intltool.mk INTLTOOL_SOURCE = intltool-$(INTLTOOL_VERSION).tar.bz2 · line 13

Quoted 3 lines

HOST_INTLTOOL_DEPENDENCIES = host-libxml-parser-perl

package/intltool/intltool.mk +0 -2
-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.

#4 lore raw

PATCH 1/3 intltool: no business defining PERLLIB

Hello,

Le Mon, 12 Mar 2012 07:14:51 -0300,
Gustavo Zacarias <[email protected]> a ?crit :

Quoted 7 lines
Quoted 7 lines

package/intltool/intltool.mk INTLTOOL_SOURCE = intltool-$(INTLTOOL_VERSION).tar.bz2 · line 13

Quoted 3 lines

HOST_INTLTOOL_DEPENDENCIES = host-libxml-parser-perl

package/intltool/intltool.mk +0 -2
-HOST_INTLTOOL_CONF_OPT = \
-  PERLLIB=$(HOST_DIR)/usr/lib/perl

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

Quoted 6 lines
Quoted 1 line

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

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
author
#5 lore raw

PATCH 1/3 intltool: no business defining PERLLIB

Quoted 9 lines · Thomas Petazzoni

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.

#6 lore raw

PATCH 1/3 intltool: no business defining PERLLIB

In reply to Gustavo Zacarias

Le Sun, 11 Mar 2012 22:58:49 -0300,
Gustavo Zacarias <[email protected]> a ?crit :

Quoted 1 line

$(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

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#7 lore raw

PATCH 1/3 intltool: no business defining PERLLIB

In reply to Gustavo Zacarias

Le Sun, 11 Mar 2012 22:58:49 -0300,
Gustavo Zacarias <[email protected]> a ?crit :

Quoted 10 lines
Signed-off-by Gustavo Zacarias <[email protected]>
---
 package/intltool/intltool.mk |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)
package/intltool/intltool.mk +0 -0
index 6d13cc1..1e749ea 100644

package/intltool/intltool.mk INTLTOOL_SOURCE = intltool-$(INTLTOOL_VERSION).tar.bz2 · line 13

Quoted 5 lines
package/intltool/intltool.mk +0 -2
@@ -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'
>>> host-intltool 0.40.6 Configuring
(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

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
author
#8 lore raw

PATCH 1/3 intltool: no business defining PERLLIB

Quoted 26 lines · Thomas Petazzoni

Le Sun, 11 Mar 2012 22:58:49 -0300,
Gustavo Zacarias <[email protected]> a ?crit :

Quoted 16 lines
Signed-off-by Gustavo Zacarias <[email protected]>
---
 package/intltool/intltool.mk |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)
package/intltool/intltool.mk +0 -0
index 6d13cc1..1e749ea 100644
@@ -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

package/intltool/intltool.mk INTLTOOL_SOURCE = intltool-$(INTLTOOL_VERSION).tar.bz2 · line 13

Quoted 2 lines
package/intltool/intltool.mk +0 -2
-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.

Quoted 3 lines

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.

#9 lore raw

PATCH 1/3 intltool: no business defining PERLLIB

Le Mon, 19 Mar 2012 12:52:04 -0300,
Gustavo Zacarias <[email protected]> a ?crit :

Quoted 1 line

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.

Quoted 9 lines

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

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
author
#10 lore raw

PATCH 1/3 intltool: no business defining PERLLIB

Quoted 9 lines · Thomas Petazzoni

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.

Quoted 7 lines

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.

#11 lore raw

PATCH 1/3 intltool: no business defining PERLLIB

In reply to Thomas Petazzoni
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Thomas> Le Mon, 19 Mar 2012 12:52:04 -0300, Thomas> Gustavo Zacarias <[email protected]> a ?crit :

Quoted 1 line
Quoted 1 line

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.

Signature · 1 line
Bye, Peter Korsgaard
#12 lore raw

PATCH 1/3 intltool: no business defining PERLLIB

Le Mon, 19 Mar 2012 17:22:00 +0100,
Peter Korsgaard <[email protected]> a ?crit :

Quoted 6 lines
Quoted 1 line
Quoted 1 line

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

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
author
#13 lore raw

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

In reply to Gustavo Zacarias

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

Signed-off-by Gustavo Zacarias <[email protected]>
---
 package/libxml-parser-perl/libxml-parser-perl.mk |   18 +++++++-----------
 1 files changed, 7 insertions(+), 11 deletions(-)
package/libxml-parser-perl/libxml-parser-perl.mk +7 -11
index 9e6f2ec..0bcda5d 100644
@@ -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))
-
Signature · 1 line
1.7.3.4
#14 lore raw

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

Le Sun, 11 Mar 2012 22:58:50 -0300,
Gustavo Zacarias <[email protected]> a ?crit :

Quoted 1 line

$(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

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
author
#15 lore raw

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

Quoted 10 lines · Thomas Petazzoni

Le Sun, 11 Mar 2012 22:58:50 -0300,
Gustavo Zacarias <[email protected]> a ?crit :

Quoted 1 line

$(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.

#16 lore raw

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

In reply to Gustavo Zacarias

Hello,

Le Sun, 11 Mar 2012 22:58:50 -0300,
Gustavo Zacarias <[email protected]> a ?crit :

package/libxml-parser-perl/libxml-parser-perl.mk line 14

Quoted 10 lines
package/libxml-parser-perl/libxml-parser-perl.mk +2 -1
-LIBXML_PARSER_PERL_DEPENDENCIES = expat
+LIBXML_PARSER_PERL_VERSION = 2.36
+LIBXML_PARSER_PERL_SOURCE =

XML-Parser-$(LIBXML_PARSER_PERL_VERSION).tar.gz

package/libxml-parser-perl/libxml-parser-perl.mk +3 -1
+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

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
author
#17 lore raw

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

Quoted 25 lines · Thomas Petazzoni

Hello,

Le Sun, 11 Mar 2012 22:58:50 -0300,
Gustavo Zacarias <[email protected]> a ?crit :

package/libxml-parser-perl/libxml-parser-perl.mk line 14

Quoted 11 lines
package/libxml-parser-perl/libxml-parser-perl.mk +2 -1
-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/

package/libxml-parser-perl/libxml-parser-perl.mk +2 -1
+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.

Quoted 5 lines

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.

#18 lore raw

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

Hello,

Le Mon, 12 Mar 2012 07:07:33 -0300,
Gustavo Zacarias <[email protected]> a ?crit :

Quoted 3 lines

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.

Quoted 2 lines

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?

Quoted 5 lines

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?

Quoted 4 lines

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.

Quoted 2 lines

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.

Quoted 4 lines

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.

Quoted 2 lines

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

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
author
#19 lore raw

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

Quoted 11 lines · Thomas Petazzoni

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.

Quoted 4 lines
Quoted 2 lines

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.

Quoted 9 lines

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.

Quoted 3 lines

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.

Quoted 7 lines

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.

Quoted 3 lines

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.

author
#20 lore raw

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

In reply to 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 <[email protected]>
---
 package/microperl/microperl.mk |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)
package/microperl/microperl.mk +6 -1
index d5b5a7c..74d7046 100644
@@ -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
Signature · 1 line
1.7.3.4