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
