Patchwork [05/13] perl: add GDBM_File

login
register
mail settings
Submitter Francois Perrad
Date Sept. 8, 2012, 12:28 p.m.
Message ID <1347107325-4163-5-git-send-email-francois.perrad@gadz.org>
Download mbox | patch
Permalink /patch/182559/
State Superseded
Headers show

Comments

Francois Perrad - Sept. 8, 2012, 12:28 p.m.
Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
---
 package/perl/Config.in |    6 ++++++
 package/perl/perl.mk   |    3 +++
 2 files changed, 9 insertions(+)
Thomas Petazzoni - Sept. 20, 2012, 7:59 p.m.
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
Francois Perrad - Sept. 21, 2012, 6:36 p.m.
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
Thomas Petazzoni - Sept. 21, 2012, 7:01 p.m.
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
Arnout Vandecappelle - Sept. 24, 2012, 8:43 a.m.
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

Patch

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)