Re: How to install config.h
On Mon, Oct 30, 2000 at 09:18:42AM -0800, Ossama Othman wrote: Hi Gary, On Fri, Oct 27, 2000 at 08:44:40PM +0100, Gary V. Vaughan wrote: Hmmm. I think that installing config.h is a bad idea under any circumstances. I talk about this in some detail in the ``Project'' chapters of the Goat Book (linked from my homepages), and offer an ugly but functional solution. Even if you don;'t go for that solution all out, there is no getting away from the fact that a certain amount of rewriting is an absolute must. I'm not sure that I agree with you, though I confess that I probably haven't thought about this issue as much as you. Please feel free to correct me. :-) If the macros placed in the package specific config.h are named so that they are specific to the given package then why is installing that header a problem. For example, if my config header has the following: /* I'm assuming that "FOO" is a fairly unique package name. */ #ifndef FOO_CONFIG_H #define FOO_CONFIG_H #define FOO_HAS_SOME_FEATURE 1 #define FOO_HAS_ANOTHER_FEATURE 1 #endif /* FOO_CONFIG_H */ That's right. You are actually agreeing with me here. Before you can install foo's config.h, you must take all of the HAVE_BAR macros and rewrite them to say FOO_HAVE_BAR... then the defined macros would presumably not conflict with macros in other headers. Sure another package may potentially use macros with the same name but at least some reconciliation can be achieved between the package authors. I do agree that the use of macros in a config.h such as "PACKAGE," "VERSION" and "HAVE_*" is a bad thing since they are named generically. It would be nice if it was possible to make autoconf prepend a package name, for example, to such automatically defined macros. That would at least help alleviate the problem. Yup. If autoconf rewrote the header for you, there would no longer be any need to do it manually before installing. Cheers, Gary. -- ___ _ ___ __ _ mailto: [EMAIL PROTECTED] / __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ [EMAIL PROTECTED] | (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \ \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/ home page: /___/ /___/ gpg public key: http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/key.asc
Re: How to install config.h
On Mon, 30 Oct 2000, Bob Friesenhahn wrote: If we should not be installing config.h files, then it would be beneficial for Automake (or Autoconf) to support an automated way to provide the benefits of config.h, but in a better form. How about the bin/package-config approach: configure creates a script that outputs gcc options necessary for compiling (-L, -R and -l). GTK uses this, and I've found it useful (along with providing an aclocal file). Simon -- GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc Fingerprint: A319 A60F 20F6 C8A4 3C86 54B4 99CD AC6E 79D1 B1E7 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
Re: How to install config.h
On Mon, Oct 30, 2000 at 07:41:21PM -0600, Bob Friesenhahn wrote: : If we should not be installing config.h files, then it would be : beneficial for Automake (or Autoconf) to support an automated way to : provide the benefits of config.h, but in a better form. You can use the generated config.status script directly from your Makefile.am to generate a customized config-header during the build process, or do it after AC_OUTPUT in configure.in to do it as part of the configure process. Lars J
Re: How to install config.h
Some food for thought: On Thu, Oct 26, 2000 at 02:20:10PM -0700, Ossama Othman wrote: Hi Alexandre, On Thu, Oct 26, 2000 at 07:13:28PM -0200, Alexandre Oliva wrote: If you really want to have it installed, don't call it `config.h', or at least install it in include/your-package-name. To accomplish that, use: pkginclude_HEADERS = config.h ... And use `#include your-package-name/config.h' in all other headers that include it. Ah! Good call Alexandre! Robert, please ignore my last post. Installing config.h in /usr/local/include, for example, would be obviously be bad idea. :-) Hmmm. I think that installing config.h is a bad idea under any circumstances. I talk about this in some detail in the ``Project'' chapters of the Goat Book (linked from my homepages), and offer an ugly but functional solution. Even if you don;'t go for that solution all out, there is no getting away from the fact that a certain amount of rewriting is an absolute must. BTW, I do exactly what Alexandre suggests in some of my own packages. It works out quite nicely. Well, imagine what will happen when someone wants to use your package from their own automake project... presumably they will check for installation with a foo-config or suchlike, and will need to use one of the headers you installed to prototype api calls their project requires. If you needed to install your config.h, that must be because you need to use it from your other installed header files, therefor if their project #includes one of those, they are implicitly including your config.h. Why is this bad? For example, you have `#define PACKAGE "myproject"' which clashes with their `#define PACKAGE "theirproject". Lots of other stuff can go horribly wrong too. Unfortunately, people are being lulled into a false sense of security, because installing config.h appears to work while it is an uncommon practice. Things will go downhill fast if this becomes common practice -- imagine the chaos that we would have if gtk.h indirectly #included a raw (i.e. with rewriting prior to installation) config.h, which set up a whole bunch of HAVE_foo macros and VERSION's that you don't want to cope with when you use libgtk. Even worse what if the gnome headers installed another conig.h with overlapping and contradicting macros Cheers, Gary. -- ___ _ ___ __ _ mailto: [EMAIL PROTECTED] / __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ [EMAIL PROTECTED] | (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \ \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/ home page: /___/ /___/ gpg public key: http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/key.asc
Re: How to install config.h
Hi Gary, On Fri, Oct 27, 2000 at 08:44:40PM +0100, Gary V. Vaughan wrote: Hmmm. I think that installing config.h is a bad idea under any circumstances. I talk about this in some detail in the ``Project'' chapters of the Goat Book (linked from my homepages), and offer an ugly but functional solution. Even if you don;'t go for that solution all out, there is no getting away from the fact that a certain amount of rewriting is an absolute must. I'm not sure that I agree with you, though I confess that I probably haven't thought about this issue as much as you. Please feel free to correct me. :-) If the macros placed in the package specific config.h are named so that they are specific to the given package then why is installing that header a problem. For example, if my config header has the following: /* I'm assuming that "FOO" is a fairly unique package name. */ #ifndef FOO_CONFIG_H #define FOO_CONFIG_H #define FOO_HAS_SOME_FEATURE 1 #define FOO_HAS_ANOTHER_FEATURE 1 #endif /* FOO_CONFIG_H */ then the defined macros would presumably not conflict with macros in other headers. Sure another package may potentially use macros with the same name but at least some reconciliation can be achieved between the package authors. I do agree that the use of macros in a config.h such as "PACKAGE," "VERSION" and "HAVE_*" is a bad thing since they are named generically. It would be nice if it was possible to make autoconf prepend a package name, for example, to such automatically defined macros. That would at least help alleviate the problem. -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Re: How to install config.h
Assar Westerlund wrote: Robert Boehne [EMAIL PROTECTED] writes: I have a massive set of C++ libraries that use CVS libtool, autoconf and automake to build and install. Since users then need to have _all_ the header files they also need to have the configure generated config.h What is the "best" way to coerce Automake into installing config.h in $(prefix) ? I must caution against installing config.h. You will collide with the potential same config.h and HAVE* et al defines that the application using your header files has figured out for itself. It's much preferable to make sure that the installed include-files do not depend on the autoconf'd parameters in any way. If you really need to use the definitions that configure has figured out for you, it's much better, I think, to partial-evaluate so that instead of: Thanks everyone for all the input! I'm still in a bind though, I would prefer NOT to install 12,000 atltered header files for each platform, the package assumes binaries in a particular location relative from the source directories, and I do agree that "config.h" is probably the worst name I could install it as. So I think the practial "solution" for now is to install the header in $(prefix) as somthing other than "config.h". Why? I simply don't have the time or patience to re-arrange the tens of thousands of source files into a GNU conforming structure and then convince the maintainers that GNU automake requires it. People are comfortable with what is familiar, I don't want to morph this project into somthing that the originators won't recognize. I'm gnuing my best here... -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: [EMAIL PROTECTED]
Re: How to install config.h
Ossama Othman [EMAIL PROTECTED] writes: On Fri, Oct 27, 2000 at 08:44:40PM +0100, Gary V. Vaughan wrote: Hmmm. I think that installing config.h is a bad idea under any circumstances. I talk about this in some detail in the ``Project'' chapters of the Goat Book (linked from my homepages), and offer an ugly but functional solution. Even if you don;'t go for that solution all out, there is no getting away from the fact that a certain amount of rewriting is an absolute must. I'm not sure that I agree with you, though I confess that I probably haven't thought about this issue as much as you. Please feel free to correct me. :-) But, you seem to agree ;-) If the macros placed in the package specific config.h are named so that they are specific to the given package then why is installing that header a problem. For example, if my config header has the following: /* I'm assuming that "FOO" is a fairly unique package name. */ #ifndef FOO_CONFIG_H #define FOO_CONFIG_H #define FOO_HAS_SOME_FEATURE 1 #define FOO_HAS_ANOTHER_FEATURE 1 #endif /* FOO_CONFIG_H */ This is one of the possible rewriting (though he doesn't talk about that in his book). The other approach, used in glib (and is explained in his book), is to use that information to precompute some of the results of those '#define's rather than use the boring #ifdef FOO_HAS_.../#endif mess in the other header files. This at least pays back for installing a config specific header by making the rest of the headers more readable. I do agree that the use of macros in a config.h such as "PACKAGE," "VERSION" and "HAVE_*" is a bad thing since they are named generically. It would be nice if it was possible to make autoconf prepend a package name, for example, to such automatically defined macros. That would at least help alleviate the problem. You can do that yourself sed 's,^#define ,#define FOO_,' config.h foo-config.h I would be loath to changing autoconf to make installing config.h more convenient. The whole philosophy of config.h is that it is used to improve the portablility of the particular package it's generated for, not as a general portability helper. In other words, wanting to install config.h is itself the problem ;-) There is also the problem with installing something that depends on the output of a configure run into $prefix. The proper home for such beasts is $exec_prefix. It would be nice if there was an $(execincludedir) [= $(exec_prefix)/include]. - Hari -- Raja R Harinath -- [EMAIL PROTECTED] "When all else fails, read the instructions." -- Cahn's Axiom "Our policy is, when in doubt, do the right thing." -- Roy L Ash
Re: How to install config.h
Hi Hari, On Mon, Oct 30, 2000 at 11:51:10AM -0600, Raja R Harinath wrote: Ossama Othman [EMAIL PROTECTED] writes: I'm not sure that I agree with you, though I confess that I probably haven't thought about this issue as much as you. Please feel free to correct me. :-) But, you seem to agree ;-) About headers that use generically named macros like PACKAGE, VERSION and HAVE_* as automatically generated by autoconf/automake, yes. Package specific macros, not necessarily. :-) The other approach, used in glib (and is explained in his book), is to use that information to precompute some of the results of those '#define's rather than use the boring #ifdef FOO_HAS_.../#endif mess in the other header files. This at least pays back for installing a config specific header by making the rest of the headers more readable. That's an interesting approach. I'll download the glib sources and take a look. Thanks for the pointer! You can do that yourself sed 's,^#define ,#define FOO_,' config.h foo-config.h Quite right, though I don't see the need to change the name of the header file if the header is placed in $pkgincludedir. As Gary points out, the macros will be included indirectly at some point so changing the name of the header file won't help. I would be loath to changing autoconf to make installing config.h more convenient. The whole philosophy of config.h is that it is used to improve the portablility of the particular package it's generated for, not as a general portability helper. In other words, wanting to install config.h is itself the problem ;-) I see your point, but it is sometimes hard to avoid installing a config.h, particularly when autoconfiscating an application that makes heave use of macros. However, I do like the idea of precomputing the results as you point out above. -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Re: How to install config.h
Ossama Othman [EMAIL PROTECTED] writes: If the macros placed in the package specific config.h are named so that they are specific to the given package then why is installing that header a problem. I would agree with Gary here that the symptom is installing the config.h (or whatever it's called). The problem is that the interface exported from the library should not depend on the parameters found out by configure. /assar
Re: How to install config.h
Hi Assar, On Tue, Oct 31, 2000 at 01:40:30AM +0100, Assar Westerlund wrote: I would agree with Gary here that the symptom is installing the config.h (or whatever it's called). The problem is that the interface exported from the library should not depend on the parameters found out by configure. Yes! I certainly do agree with you on this point. However, sometimes this can't be avoided in the case of inlined functions (e.g. C++). It isn't always feasible, particularly in terms of performance, to always keep function implementations hidden within the library. One could argue that the inlined functions shouldn't depend on the output of configure. On that point, I would agree. If you had a solution for this problem then I'd be eternally grateful! :-) -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Re: How to install config.h
On Mon, 30 Oct 2000, Ossama Othman wrote: On Tue, Oct 31, 2000 at 01:40:30AM +0100, Assar Westerlund wrote: I would agree with Gary here that the symptom is installing the config.h (or whatever it's called). The problem is that the interface exported from the library should not depend on the parameters found out by configure. Yes! I certainly do agree with you on this point. However, sometimes this can't be avoided in the case of inlined functions (e.g. C++). It Besides inlined functions, it is not uncommon to see data structures changing in size, either because there are additional members, or the size of members has changed. If we should not be installing config.h files, then it would be beneficial for Automake (or Autoconf) to support an automated way to provide the benefits of config.h, but in a better form. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: How to install config.h
Hi, Ossama. Ossama Othman [EMAIL PROTECTED] writes: However, sometimes this can't be avoided in the case of inlined functions (e.g. C++). It isn't always feasible, particularly in terms of performance, to always keep function implementations hidden within the library. One could argue that the inlined functions shouldn't depend on the output of configure. On that point, I would agree. If you had a solution for this problem then I'd be eternally grateful! :-) In that case, I would vote for the solution already mentioned by me and other people in this thread, namely to generate header files so that they don't depend on the configure variables, which obviously has the downside of making them machine-dependent. /assar
Re: How to install config.h
Robert Boehne [EMAIL PROTECTED] writes: I have a massive set of C++ libraries that use CVS libtool, autoconf and automake to build and install. Since users then need to have _all_ the header files they also need to have the configure generated config.h What is the "best" way to coerce Automake into installing config.h in $(prefix) ? I must caution against installing config.h. You will collide with the potential same config.h and HAVE* et al defines that the application using your header files has figured out for itself. It's much preferable to make sure that the installed include-files do not depend on the autoconf'd parameters in any way. If you really need to use the definitions that configure has figured out for you, it's much better, I think, to partial-evaluate so that instead of: bar.h: #ifdef HAVE_FOO_H #include foo.h #endif you make it unconditional (empty or just with the include). This will make that file machine-dependent, but you can most likely limit this to one file and have all the other header files be shared. And if you install config.h, it should be as PACKAGE-config.h. /assar
Re: How to install config.h
And use `#include your-package-name/config.h' in all other headers that include it. Ossama BTW, I do exactly what Alexandre suggests in some of my Ossama own packages. It works out quite nicely. But be careful: if any of the C code in the package itself includes your-package-name/config.h you might be in for a nasty surprise: if a version is already installed and a user is compiling a new version from source, that user will pick up the installed .h files which will not be consistent with the source. I've seen this happen.
Re: How to install config.h
Hi, On Fri, Oct 27, 2000 at 09:30:47PM +0200, Simon Richter wrote: On 27 Oct 2000, Mark Galassi wrote: [Installing config.h] But be careful: if any of the C code in the package itself includes your-package-name/config.h you might be in for a nasty surprise: if a version is already installed and a user is compiling a new version from source, that user will pick up the installed .h files which will Even more evil: These files will contain definitions for PACKAGE and VERSION. Not if you give AM_INIT_AUTOMAKE the dummy third argument. -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Re: How to install config.h
Simon Richter [EMAIL PROTECTED] writes: On 27 Oct 2000, Mark Galassi wrote: [Installing config.h] But be careful: if any of the C code in the package itself includes your-package-name/config.h you might be in for a nasty surprise: if a version is already installed and a user is compiling a new version from source, that user will pick up the installed .h files which will Even more evil: These files will contain definitions for PACKAGE and VERSION. And unless the configure.in tests are exactly the same, you'll have HAVE_* conflicts. Compare (on Solaris) AC_CHECK_LIB(resolv, inet_aton) #define HAVE_RESOLV 1 AC_CHECK_FUNC(inet_ntoa)#define HAVE_INET_NTOA vs. AC_CHECK_LIB(resolv, inet_aton, RESOLV_LIB=-lresolv) #define HAVE_RESOLV 1 AC_CHECK_FUNC(inet_ntoa) #undef HAVE_INET_NTOA (I know, in "reasonable" circumstances, this example won't really cause problems, even with both config.h being included.) And, then we have the problem of having anything depending on the output of config.status going into $prefix rather than $exec_prefix. - Hari -- Raja R Harinath -- [EMAIL PROTECTED] "When all else fails, read the instructions." -- Cahn's Axiom "Our policy is, when in doubt, do the right thing." -- Roy L Ash
How to install config.h
I have a massive set of C++ libraries that use CVS libtool, autoconf and automake to build and install. Since users then need to have _all_ the header files they also need to have the configure generated config.h What is the "best" way to coerce Automake into installing config.h in $(prefix) ? -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: [EMAIL PROTECTED]
Re: How to install config.h
On Thu, 26 Oct 2000, Robert Boehne wrote:
[Finding libraries from other packages]
What is the "best" way to coerce Automake into installing
config.h in $(prefix) ?
Not at all. Instead, create m4 macros that search for the libraries
somehow and place them in ${datadir}/aclocal. A common search method is to
create small scripts (from .in files) that echo the necessary paths and
place them in ${bindir}, as @PACKAGE@-config (For C++, this is the only
rational method with the currently released autoconf). See for example the
gtk packages, they do a very good job here.
Anyone wishing to use your library just needs to use the macros you
provided to get the necessary compiler flags.
Simon
--
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
Fingerprint: A319 A60F 20F6 C8A4 3C86 54B4 99CD AC6E 79D1 B1E7
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
Re: How to install config.h
Ossama Othman wrote: Hi Alexandre, On Thu, Oct 26, 2000 at 07:13:28PM -0200, Alexandre Oliva wrote: If you really want to have it installed, don't call it `config.h', or at least install it in include/your-package-name. To accomplish that, use: pkginclude_HEADERS = config.h ... And use `#include your-package-name/config.h' in all other headers that include it. Ah! Good call Alexandre! Robert, please ignore my last post. Installing config.h in /usr/local/include, for example, would be obviously be bad idea. :-) BTW, I do exactly what Alexandre suggests in some of my own packages. It works out quite nicely. -Ossama In my case I need to support several platforms in the same directory tree, not because I think this is a good idea, but I can't change the package's current framework. So in my case users are encouraged to use NFS (or similar) for installing multiple architectures in the same directory tree. i.e.: $(prefix) = $(srcdir)/`uname` That way users do not have to copy the 12,000 header files, yes that is the right number, not a typo, and they aren't small either. (I guess I'm more ambitious than wise.) So to use the library users would add -I$(prefix)/`uname` (for config.h) and -I$(prefix)/../inc (for the other 12,000) to compile lines and -L$(prefix)/lib to link lines. So you may think this is a train wreck, but it is better than the csh scripts that are currently distributed -- no joke, csh! With that said, is pkginclude_HEADERS = config.h a reasonable solution? -- Robert Boehne Very tired Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: [EMAIL PROTECTED]
