autoconf
[Top][All Lists]
Advanced

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

Re: Solving the config.h nightmare ?


From: Olivier Boudeville
Subject: Re: Solving the config.h nightmare ?
Date: Sat, 22 Apr 2006 23:51:41 +0200
User-agent: Mozilla Thunderbird 1.0.7 (X11/20051013)

Hi,

it is an interesting solution indeed but I would rather not rely on my
hand-crafted stripped-down config.h maintaining ! I will try the
prefix-adding first.

Thanks,

Olivier.

(sorry for the double mail, I had forgotten to answer to the list as well)


Bob Friesenhahn a écrit :

> On Sat, 22 Apr 2006, Olivier Boudeville wrote:
>
>>
>> I am writing a library, called 'Ceylan', which has to be configured so
>> that, depending on the user requests and the underlying platform, some
>> features are activated or not.
>>
>> My problem is that it results in my main header file ('Ceylan.h')
>> depending on 'CeylanConfig.h' (a renamed 'config.h' thanks to
>> AC_CONFIG_HEADERS), i.e. some sub-headers *have* to include
>> 'CeylanConfig.h' to enable/disable some portions of the exposed API
>> (besides, some signatures have to mention types such as mode_t, pid_t,
>> size_t, pthread_mutex_t, etc. which results in the need of having #ifdef
>> HAVE_UNISTD_H, thus the config file).
>
>
> Many exotic techniques have been described for how to get rid of the
> dreaded installed "config.h" file. None of them are perfect.
>
> This is the approach I use for my own package:
>
> 1) Two different configuration headers are generated from configure.ac:
>
> AC_CONFIG_HEADERS([magick/magick_config.h magick/magick_config_api.h])
>
> the second one uses a hand-maintained template (derived from the
> primary one) and only includes what is absolutely necessary in order
> to support the library API.
>
> 2) When the software is installed, the pared down configuration header
> is installed where the moby one would go:
>
> install-data-local:
> $(INSTALL_HEADER) magick/magick_config_api.h
> $(DESTDIR)$(magickincdir)/magick_config.h
>
> Of course the install path needs to be adjusted for the needs of your
> own package.
>
> 3) Step #3 is still being invented, and acts as a placeholder in case
> I left anything out.
>
> This approach can still collide with configuration defines from the
> config headers from other headers, but the collision should usually be
> benign. Other approaches may add a prefix to all #define names.
>
> Bob
> ======================================
> Bob Friesenhahn
> address@hidden,
> http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
>
>





reply via email to

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