From: Maurice L. <mj...@ga...> - 2003-01-29 10:35:36
|
Rafael Laboissiere writes: > * Maurice LeBrun <mj...@ga...> [2003-01-27 17:29]: > > > BTW I just ran into another irritating side effect of the current > > configuration system. Running a recursive search from the top level > > shows up HAVE_CONFIG_H defined throughout: > > > > ./bindings/c++/Makefile:DEFS = -DHAVE_CONFIG_H > > ... > > > > Well the problem occurs when including headers from some gnu tools such as > > readline. In /usr/include/readline/tilde.h -- > > > > #if defined (HAVE_CONFIG_H) > > # include <config.h> > > #endif > > > > Whoops. I guess when this happens we'll just have to #undef HAVE_CONFIG_H > > but that seems pretty lame.. is there any way to turn off this define? > > I think that there is a logical justification for having this define, > provided that we proceed like it is advised in the autoconf documentation. > We should replace all instances of `#include "plConfig.h"', by: > > #if HAVE_CONFIG_H > # include <plConfig.h> > #endif > > (cf info -f /usr/share/info/autoconf.info.gz -n "Configuration Headers") > > I am making the assumption that all the definitions in plConfig.h are > useful only when compiling PLplot itself and are irrelevant for user's > applications linked against PLplot. Is that true? Well, no, and that's part of the problem. The other part of the problem is that certain gnu headers we may want to include assert that #if defined (HAVE_CONFIG_H) then # include <config.h> must succeed which in our case it doesn't of course. I guess this way of handling it among "gnu programs" represents some sort of overall plan but I don't like it much. To me either you should keep the config details private or export them publically, one or the other. Not magically expect a certain header file to be present if a certain define is made. That's ok for the system headers, but not in application space. We have plConfig.h which gets injected in the user namespace because it *is* useful. This is what I was talking about when I complained about our big problem with all the symbols we probably *shouldn't* be injecting into the user namespace. E.g. here's some vanilla autoconf stuff in plConfig.h that probably shouldn't appear in the user namespace: /* Define to 1 if you have the <dlfcn.h> header file. */ #define HAVE_DLFCN_H 1 /* Define to 1 if you have the `fork' function. */ #define HAVE_FORK 1 /* Define to 1 if you have the <inttypes.h> header file. */ #define HAVE_INTTYPES_H 1 /* Define to 1 if you have the <memory.h> header file. */ #define HAVE_MEMORY_H 1 etc, etc. OTOH, here are some things in plConfig.h that are definitely or may be useful to the application writer: /* If you don't know what this is for, you shouldn't be using it */ /* #undef NOBRAINDEAD */ /* Define if dynamic drivers are enabled.*/ #define ENABLE_DYNDRIVERS 1 /* Define if drivers database is specified.*/ #define DRIVERS_DB "drivers.db" /* Define if [incr Tcl] is available */ #define HAVE_ITCL 1 /* Define if [incr Tk] is available */ #define HAVE_ITK 1 /* Define if [freetype] is available */ /* #undef HAVE_FREETYPE */ /* Define if you want PLplot's float type to be double */ /* #undef PL_DOUBLE */ /* Install directories. */ #define LIB_DIR "/home/mjl/tools/lib" #define DATA_DIR "/home/mjl/tools/lib/plplot5.2.0/data" #define BIN_DIR "/home/mjl/tools/bin" #define TCL_DIR "/home/mjl/tools/lib/plplot5.2.0/tcl" /* Name of package */ #define PACKAGE "plplot" /* Define to the address where bug reports for this package should be sent. */ #define PACKAGE_BUGREPORT "" /* Define to the full name of this package. */ #define PACKAGE_NAME "" /* Define to the full name and version of this package. */ #define PACKAGE_STRING "" /* Define to the one symbol short name of this package. */ #define PACKAGE_TARNAME "" /* Define to the version of this package. */ #define PACKAGE_VERSION "" /* Version number of package */ #define VERSION "5.2.0" Some of these reflect facts about the package, others about how it was configured when installed. In summary: - There should be a clear distinction drawn between these two different styles of defines. One is useful to the user, the other essentially only useful internally. - The assumption present in some GNU packages that the existence of the HAVE_CONFIG_H define implies the existence of a config.h header is at odds with our current configuration. We should fix this. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Rafael L. <lab...@ps...> - 2003-01-29 11:45:43
|
Thanks, Maurice, for the very clear message stating exactly what the problem is. * Maurice LeBrun <mj...@ga...> [2003-01-29 04:34]: > In summary: > > - There should be a clear distinction drawn between these two different > styles of defines. One is useful to the user, the other essentially only > useful internally. > > - The assumption present in some GNU packages that the existence of the > HAVE_CONFIG_H define implies the existence of a config.h header is at > odds with our current configuration. We should fix this. I think that the right approach to this is to create a top-level config.h file (eventually using autoheader) that will contain all the defines that shouldn't appear in the user namespace and remove them from plConfig.h. In plConfig.h, we add: #if HAVE_CONFIG_H # include <config.h> #endif Remeber that -DHAVE_CONFIG_H is automatically added by automake to the CFLAGS when the package is built, so the scheme above should work. Now, when users will compile their applications linked against the PLplot library, the config.h file will not be included, unless they (foolishly and unnecessarily) #define HAVE_CONFIG_H. In configure.ac, we should use: AC_CONFIG_HEADERS([config.h include/plConfig.h include/plDevs.h]) Notice that there is a beneficial side-effect to this: many of the autoheader problems that we were experiencing may be fixed, since autoheader only acts on the first argument of the macro AC_CONFIG_HEADERS. What do you think? > I guess this way of handling it among "gnu programs" represents some sort > of overall plan but I don't like it much. I do not think that this is an overall plan, but a convinience to only include build-related definitions at build time. -- Rafael |
From: Maurice L. <mj...@ga...> - 2003-01-30 04:41:56
|
Rafael Laboissiere writes: > I think that the right approach to this is to create a top-level config.h > file (eventually using autoheader) that will contain all the defines that > shouldn't appear in the user namespace and remove them from plConfig.h. In > plConfig.h, we add: > > #if HAVE_CONFIG_H > # include <config.h> > #endif > > Remeber that -DHAVE_CONFIG_H is automatically added by automake to the > CFLAGS when the package is built, so the scheme above should work. > > Now, when users will compile their applications linked against the PLplot > library, the config.h file will not be included, unless they (foolishly and > unnecessarily) #define HAVE_CONFIG_H. > > In configure.ac, we should use: > > AC_CONFIG_HEADERS([config.h include/plConfig.h include/plDevs.h]) > > Notice that there is a beneficial side-effect to this: many of the > autoheader problems that we were experiencing may be fixed, since autoheader > only acts on the first argument of the macro AC_CONFIG_HEADERS. > > What do you think? If this works the way you describe, it sounds great. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Rafael L. <lab...@ps...> - 2003-01-30 13:25:24
|
* Maurice LeBrun <mj...@ga...> [2003-01-29 22:40]: > If this works the way you describe, it sounds great. Hopefully it works the way I described. If I find some time in the near future, I will try to implement it. As a preparation, could you please indicate which #defines in the current plConfig.h should not be exported into user's space? You already presented some of them, but I need a complete list. -- Rafael |
From: Maurice L. <mj...@ga...> - 2003-02-01 05:42:20
|
Rafael Laboissiere writes: > * Maurice LeBrun <mj...@ga...> [2003-01-29 22:40]: > > > If this works the way you describe, it sounds great. > > Hopefully it works the way I described. If I find some time in the near > future, I will try to implement it. As a preparation, could you please > indicate which #defines in the current plConfig.h should not be exported > into user's space? You already presented some of them, but I need a complete > list. Sorry I've been MIA the last few days. Do you still need this info? -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Rafael L. <lab...@ps...> - 2003-02-01 08:20:28
|
* Maurice LeBrun <mj...@ga...> [2003-01-31 23:41]: > Sorry I've been MIA the last few days. Do you still need this info? Yes, please. Alan commited my patch containing the new plConfig.h.in. Take a look at it and tell was what is lacking and what should be removed from it. -- Rafael |
From: Rafael L. <lab...@ps...> - 2003-01-27 13:02:43
|
* Alan W. Irwin <ir...@be...> [2003-01-26 16:23]: > On Sun, 26 Jan 2003, Rafael Laboissiere wrote: > > > This is a complete non-sense, since there are no src/plConfig.h.in and > > src/plDevs.h.in to be built! This is what is triggering the call to > > autoheader from make, which should never, I repeat, never occurs for regular > > users. > > Actually, this makes sense. Remember, $(srcdir) is the current directory, > i.e., include. You are fully right, I have overseen this. The problem, as you wrote, is related to dependencies on plDevs.h.in included in the file include/Makefile.in by automake. I could look art the problem more closely, and will probably send a message to plplot-devel tonight. -- Rafael |