bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Conditional inclusion


From: Bruno Haible
Subject: Re: Conditional inclusion
Date: Mon, 15 Oct 2007 02:08:18 +0200
User-agent: KMail/1.5.4

Hi,

Micah Cowan asked:
> If I've --import'ed md5, is there a means for me to specify in
> configure.ac that it should not be included in certain circumstances?

Depending on what you want, there are different answers:

1) If it's ok to build the module even though it does not get used -
   this is usually the case if you build libgnu.a as a static library
   and it is not installed, only used to link an executable - then
   simply leave the module in the list.

2) If the condition when to use the module is a simple one that can be
   determined at configure time, you can put all code that is subject to
   the same condition into a library that is built conditionally. Call
   this library, say, libwcrypt. Then you will have two gnulib-tool
   invocations, one for libgnu, one for libwcrypt. They have to have
   their sources in different directories (a limitation of gnulib-tool).
   I.e. you will have two directories 'gl' and 'wcrypt', and your Makefile.am
   will contain this:

        if ENABLE_LIBWCRYPT
        SUBDIR_wcrypt = wcrypt
        else
        SUBDIR_wcrypt =
        endif
        SUBDIRS = gl $(SUBDIR_wcrypt) src doc po ...

   Such declarations will prevent "make" from recursing into wcrypt.
   But this poses problems when doing "make dist", therefore an alternative
   way to do it is to always recurse into the subdirectory:

        SUBDIRS = gl wcrypt src doc po ...

   wcrypt/Makefile.am:
        if ENABLE_LIBWCRYPT
        noinst_LIBRARIES = libwcrypt.a
        else
        noinst_LIBRARIES =
        endif
        # use gnulib-tool option --makefile-name=Makefile.gnulib
        include Makefile.gnulib

3) You can also use the gnulib-tool option --local-dir and use a locally
   modified version of the module. You can use a different module description
   (referring to a .m4 file of yours), or a different .m4 macro file, or a
   different .c file that has all the code enclosed in a #endif.

   Note: This option consumes maintainer time in the long run, because you
   have to update your modified version nearly every time the original module
   changes. But if your change looks general-purpose enough, it may migrate
   into gnulib itself if the module maintainer approves it.

Bruno





reply via email to

[Prev in Thread] Current Thread [Next in Thread]