[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/
>
>
- Solving the config.h nightmare ?, Olivier Boudeville, 2006/04/22
- Re: Solving the config.h nightmare ?, Bob Friesenhahn, 2006/04/22
- Re: Solving the config.h nightmare ?, Bruce Korb, 2006/04/22
- Re: Solving the config.h nightmare ?,
Olivier Boudeville <=
- Re: Solving the config.h nightmare ?, Ralf Wildenhues, 2006/04/22
- Re: Solving the config.h nightmare ?, Russ Allbery, 2006/04/22
- Re: Solving the config.h nightmare ?, Bob Friesenhahn, 2006/04/22
- Re: Solving the config.h nightmare ?, Ralf Wildenhues, 2006/04/23
- Re: Solving the config.h nightmare ?, Russ Allbery, 2006/04/23
- Re: Solving the config.h nightmare ?, Ralf Wildenhues, 2006/04/23
- Re: Solving the config.h nightmare ?, Daniel Reed, 2006/04/23
- Re: Solving the config.h nightmare ?, Russ Allbery, 2006/04/23
- Re: Solving the config.h nightmare ?, Bob Friesenhahn, 2006/04/23
- Re: Solving the config.h nightmare ?, Daniel Reed, 2006/04/23