Hi Christophe-Marie,
On 4/28/2009 10:32 AM, Christophe-Marie Duquesne wrote:
I've read it was deprecated to deliver the file config.h generated by
autoheader (or whatever name you give it) in a project (see (1)).
I think there are several issues here that are confused.
config.h is generated by config.status from config.h.in, which is
distributed in your package, and should also be distributed in
distro-specific source packages on GNU/Linux systems.
What you should *not* do is install config.h with your devel package.
That is, config.h shouldn't be a part of your installable library's
public interface. Thus, you may include config.h in all of your internal
project header files, but not in any of your public header files that
will be installed with your libraries.
Several solutions to this problem have been formulated over the years,
including autoconf mechanisms for custom-naming your config.h file to
<package>_config.h, etc. But the best overall strategy is to design your
public interface so as to not require information from config.h in the
first place.
Regards,
John
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
