| Message ID | 1347107325-4163-5-git-send-email-francois.perrad@gadz.org |
|---|---|
| State | Superseded |
| Headers | show |
Dear Francois Perrad, On Sat, 8 Sep 2012 14:28:37 +0200, Francois Perrad wrote: > +ifdef BR2_PACKAGE_PERL_GDBM_FILE ifeq ($(BR2_PACKAGE_PERL_GDBM_FILE),y) > + PERL_DEPENDENCIES += gdbm > +endif > HOST_PERL_DEPENDENCIES = There is no configuration option or argument to pass to Perl to tell it to use Gdbm (or Berkeley DB)? I am a bit worried that if GDBM is available on the build machine (for the build machine architecture), the Perl build system might get confused and think that GDBM or Berkeley DB are available, while they are not available for the target. I.e, for autotools packages, we typically have: ifeq ($(BR2_PACKAGE_FOO_FEATURE_A),y) FOO_DEPENDENCIES += liba FOO_CONF_OPT += --enable-feature-a else FOO_CONT_OPT += --disable-feature-a endif Isn't a similar construct necessary here? Best regards, Thomas
2012/9/20 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>: > Dear Francois Perrad, > > On Sat, 8 Sep 2012 14:28:37 +0200, Francois Perrad wrote: > >> +ifdef BR2_PACKAGE_PERL_GDBM_FILE > > ifeq ($(BR2_PACKAGE_PERL_GDBM_FILE),y) ok > >> + PERL_DEPENDENCIES += gdbm >> +endif >> HOST_PERL_DEPENDENCIES = > > There is no configuration option or argument to pass to Perl to tell it > to use Gdbm (or Berkeley DB)? I am a bit worried that if GDBM is > available on the build machine (for the build machine architecture), > the Perl build system might get confused and think that GDBM or > Berkeley DB are available, while they are not available for the target. > I.e, for autotools packages, we typically have: > > ifeq ($(BR2_PACKAGE_FOO_FEATURE_A),y) > FOO_DEPENDENCIES += liba > FOO_CONF_OPT += --enable-feature-a > else > FOO_CONT_OPT += --disable-feature-a > endif > > Isn't a similar construct necessary here? > The Configure script is not created by autotools, by a tool named 'metaconfig'. So, an option --enable-gdbm is not needed. The Configure script detects the include and the lib. The parameter libc defines a path with SYSROOT, so, there is not confusion with build machine. François > Best regards, > > Thomas > -- > Thomas Petazzoni, Free Electrons > Kernel, drivers, real-time and embedded Linux > development, consulting, training and support. > http://free-electrons.com > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
Dear François Perrad, On Fri, 21 Sep 2012 20:36:45 +0200, François Perrad wrote: > The Configure script is not created by autotools, by a tool named 'metaconfig'. > So, an option --enable-gdbm is not needed. > The Configure script detects the include and the lib. > The parameter libc defines a path with SYSROOT, so, there is not > confusion with build machine. Ok, thanks! Thomas
On 09/21/12 20:36, François Perrad wrote: > 2012/9/20 Thomas Petazzoni<thomas.petazzoni@free-electrons.com>: >> On Sat, 8 Sep 2012 14:28:37 +0200, Francois Perrad wrote: >>> + PERL_DEPENDENCIES += gdbm >>> +endif >>> HOST_PERL_DEPENDENCIES = >> >> There is no configuration option or argument to pass to Perl to tell it >> to use Gdbm (or Berkeley DB)? I am a bit worried that if GDBM is >> available on the build machine (for the build machine architecture), >> the Perl build system might get confused and think that GDBM or >> Berkeley DB are available, while they are not available for the target. >> I.e, for autotools packages, we typically have: >> >> ifeq ($(BR2_PACKAGE_FOO_FEATURE_A),y) >> FOO_DEPENDENCIES += liba >> FOO_CONF_OPT += --enable-feature-a >> else >> FOO_CONT_OPT += --disable-feature-a >> endif >> >> Isn't a similar construct necessary here? >> > > The Configure script is not created by autotools, by a tool named 'metaconfig'. > So, an option --enable-gdbm is not needed. > The Configure script detects the include and the lib. > The parameter libc defines a path with SYSROOT, so, there is not > confusion with build machine. Another reason to explicitly enable/disable options is to be more robust against dependency problems. E.g. if --enable-feature-a is specified but the configure script can't find feature a, then it will (hopefully) error out and we can detect this in the autobuilders. So if metaconf allows to explicitly enable/disable features, we would prefer to use that. Regards, Arnout
diff --git a/package/perl/Config.in b/package/perl/Config.in index 9df487a..8a042cc 100644 --- a/package/perl/Config.in +++ b/package/perl/Config.in @@ -26,4 +26,10 @@ config BR2_PACKAGE_PERL_DB_FILE help Build the DB_File module. +config BR2_PACKAGE_PERL_GDBM_FILE + bool "GDBM_File" + select BR2_PACKAGE_GDBM + help + Build the GDBM_File module. + endif diff --git a/package/perl/perl.mk b/package/perl/perl.mk index 2225f0c..e0628e6 100644 --- a/package/perl/perl.mk +++ b/package/perl/perl.mk @@ -15,6 +15,9 @@ PERL_INSTALL_STAGING = YES ifdef BR2_PACKAGE_PERL_DB_FILE PERL_DEPENDENCIES += berkeleydb endif +ifdef BR2_PACKAGE_PERL_GDBM_FILE + PERL_DEPENDENCIES += gdbm +endif HOST_PERL_DEPENDENCIES = ifeq ($(shell expr $(PERL_VERSION_MAJOR) % 2), 1)
Signed-off-by: Francois Perrad <francois.perrad@gadz.org> --- package/perl/Config.in | 6 ++++++ package/perl/perl.mk | 3 +++ 2 files changed, 9 insertions(+)