I see no references to HAVE_CONFIG_H in the source code (except one #undef in readline.c), yet we #define it on the command line. Is that still necessary? --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
I see no references to HAVE_CONFIG_H in the source code (except one #undef in readline.c), yet we #define it on the command line. Is that still necessary?
What about these ? ./Mac/mwerks/old/mwerks_nsgusi_config.h: -- define HAVE_CONFIG_H ./Mac/mwerks/old/mwerks_tk_config.h: -- define HAVE_CONFIG_H ./Mac/mwerks/old/mwerks_shgusi_config.h: -- define HAVE_CONFIG_H ./Modules/expat/xmlparse.c: -- #ifdef HAVE_CONFIG_H ./Modules/expat/xmltok.c: -- #ifdef HAVE_CONFIG_H ./Modules/expat/xmlrole.c: -- #ifdef HAVE_CONFIG_H -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
I see no references to HAVE_CONFIG_H in the source code (except one #undef in readline.c), yet we #define it on the command line. Is that still necessary?
What about these ?
./Mac/mwerks/old/mwerks_nsgusi_config.h: -- define HAVE_CONFIG_H ./Mac/mwerks/old/mwerks_tk_config.h: -- define HAVE_CONFIG_H ./Mac/mwerks/old/mwerks_shgusi_config.h: -- define HAVE_CONFIG_H
I don't have a directory Mac/mwerks/old/. Maybe you created this yourself?
./Modules/expat/xmlparse.c: -- #ifdef HAVE_CONFIG_H ./Modules/expat/xmltok.c: -- #ifdef HAVE_CONFIG_H ./Modules/expat/xmlrole.c: -- #ifdef HAVE_CONFIG_H
We don't pass HAVE_CONFIG_H to extension modules, only to the core (stuff built directly by the Makefile, not by setup.py). That's a good thing too, becaus these include <config.h>, not "pyconfig.h". --Guido van Rossum (home page: http://www.python.org/~guido/)
On Monday, July 29, 2002, at 09:59 , M.-A. Lemburg wrote:
Guido van Rossum wrote:
I see no references to HAVE_CONFIG_H in the source code (except one #undef in readline.c), yet we #define it on the command line. Is that still necessary?
What about these ?
./Mac/mwerks/old/mwerks_nsgusi_config.h: -- define HAVE_CONFIG_H [...]
They're turds, they can go. -- - Jack Jansen <Jack.Jansen@oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -
Guido van Rossum <guido@python.org> writes:
I see no references to HAVE_CONFIG_H in the source code (except one #undef in readline.c), yet we #define it on the command line. Is that still necessary?
It's autoconf tradition to use that; it would replace DEFS to either many -D options, or -DHAVE_CONFIG_H (if AC_CONFIG_HEADER appears). I don't think we need this, and it can safely be removed. Regards, Martin
[Martin v. Loewis]
Guido van Rossum <guido@python.org> writes:
I see no references to HAVE_CONFIG_H in the source code (except one #undef in readline.c), yet we #define it on the command line. Is that still necessary?
It's autoconf tradition to use that; it would replace DEFS to either many -D options, or -DHAVE_CONFIG_H (if AC_CONFIG_HEADER appears).
I don't think we need this, and it can safely be removed.
The many `-D' options which appear when `AC_CONFIG_HEADER' is not used are rather inelegant, they create a lot, really a lot of clumsiness in `make' output. The idea, but you surely know it, was to regroup all auto-configured definitions into a single header file, and limit the `-D' to the sole `HAVE_CONFIG_H', or almost. While the: #if HAVE_CONFIG_H # include <config.h> #endif idiom, for some widely used sources, was to cope with `AC_CONFIG_HEADER' being defined in some projects, and not in others. There is no need to include `config.h', nor to create it, if all `#define's have been already done through a litany of `-D' options. -- François Pinard http://www.iro.umontreal.ca/~pinard
I see no references to HAVE_CONFIG_H in the source code (except one #undef in readline.c), yet we #define it on the command line. Is that still necessary?
It's autoconf tradition to use that; it would replace DEFS to either many -D options, or -DHAVE_CONFIG_H (if AC_CONFIG_HEADER appears).
I don't think we need this, and it can safely be removed.
The many `-D' options which appear when `AC_CONFIG_HEADER' is not used are rather inelegant, they create a lot, really a lot of clumsiness in `make' output. The idea, but you surely know it, was to regroup all auto-configured definitions into a single header file, and limit the `-D' to the sole `HAVE_CONFIG_H', or almost. While the:
#if HAVE_CONFIG_H # include <config.h> #endif
idiom, for some widely used sources, was to cope with `AC_CONFIG_HEADER' being defined in some projects, and not in others. There is no need to include `config.h', nor to create it, if all `#define's have been already done through a litany of `-D' options.
Since we don't use this idiom, we can safely remove the -DHAVE_CONFIG_H (if we can find where it is set). --Guido van Rossum (home page: http://www.python.org/~guido/)
Since we don't use this idiom, we can safely remove the -DHAVE_CONFIG_H (if we can find where it is set).
I looked. It's generated by AC_OUTPUT. I don't think I can get rid of it. So never mind. :-) --Guido van Rossum (home page: http://www.python.org/~guido/)
[Guido van Rossum]
Since we don't use this idiom, we can safely remove the -DHAVE_CONFIG_H (if we can find where it is set).
I looked. It's generated by AC_OUTPUT. I don't think I can get rid of it. So never mind. :-)
Maybe AC_OUTPUT, or macros called by AC_OUTPUT, can be overridden. If this is not easy to do, you might want to discuss the matter with Akim, Cc:ed. Maybe he could tear down AC_OUTPUT in parts so the overriding gets easier? I know my friend Akim as good, helping and nice fellow! Don't fear him! :-) -- François Pinard http://www.iro.umontreal.ca/~pinard
"François" == François Pinard <pinard@iro.umontreal.ca> writes:
François> [Guido van Rossum] Hi Guido, Hi Francois !
Since we don't use this idiom, we can safely remove the -DHAVE_CONFIG_H (if we can find where it is set).
I looked. It's generated by AC_OUTPUT. I don't think I can get rid of it. So never mind. :-)
François> Maybe AC_OUTPUT, or macros called by AC_OUTPUT, can be François> overridden. If this is not easy to do, you might want to François> discuss the matter with Akim, Cc:ed. Maybe he could tear François> down AC_OUTPUT in parts so the overriding gets easier? François> I know my friend Akim as good, helping and nice fellow! François> Don't fear him! :-) I'm not sure I completely understand the question here: if HAVE_CONFIG_H is specified, it means config.h is created. So if you use a config.h, why does it matter not to define HAVE_CONFIG_H?
[Akim Demaille]
I'm not sure I completely understand the question here: if HAVE_CONFIG_H is specified, it means config.h is created. So if you use a config.h, why does it matter not to define HAVE_CONFIG_H?
Hi, Akim. I hope life is still good to you! :-) In the beginnings of Autoconf, the `config.h' file did not exist. David MacKenzie added it as a way to reduce the `make' output clutter. Nowadays, I suspect almost all packages of at least moderate size uses it. Our traditional `lib/' modules have to work in many packages, whether `config.h' has been created or not, this being decided on a per package basis, and that is why there is a conditional inclusion of `config.h' in each of these `lib/' modules. He took a good while before we got stabilised on the exact stanza of this inclusion (I especially remember the massive unilateral changes by Roland McGrath introducing the BROKEN_BROKET define, or something like that, and all the doing it later took to clean this out.) Python (the distribution, which is what is in question here) does not use any of our `lib/' things, it is not going to use them, and it is not going to provide new such modules, so the distribution includes `config.h' everywhere, by permanent choice, without any need to use `HAVE_CONFIG_H' to decide if that inclusion is needed or not. So, even `-DHAVE_CONFIG_H' is useless `make' clutter in this case, and that's why the Python packagers wanted to get rid of it. In fact, in practice `-DHAVE_CONFIG_H' is only needed for packages using those common `lib/' modules, but many packages do not. Now that Autoconf is used with projects who have a life outside GNU, this is less necessary. Guido found, and got me to remember, that `@DEFS@' is the culprit: people just do not have to use it in their hand-crafted Makefiles, which is the case for Python. For away-from-GNU packages using Automake, some Automake option might exist so `@DEFS@' does not get generated? The only goal here is to get a cleaner `make' output. -- François Pinard http://www.iro.umontreal.ca/~pinard
"François" == François Pinard <pinard@iro.umontreal.ca> writes:
François> [Akim Demaille]
I'm not sure I completely understand the question here: if HAVE_CONFIG_H is specified, it means config.h is created. So if you use a config.h, why does it matter not to define HAVE_CONFIG_H?
François> Hi, Akim. I hope life is still good to you! :-) Hi François! The new (scholar) year is starting now, so life is still good, but I'm a bit afraid of what it might be done in the near future :) François> In the beginnings of Autoconf, the `config.h' file did not François> exist. David MacKenzie added it as a way to reduce the François> `make' output clutter. Nowadays, I suspect almost all François> packages of at least moderate size uses it. Agreed. François> Our traditional `lib/' modules have to work in many François> packages, whether `config.h' has been created or not, this François> being decided on a per package basis, and that is why there François> is a conditional inclusion of `config.h' in each of these François> `lib/' modules. He took a good while before we got François> stabilised on the exact stanza of this inclusion (I François> especially remember the massive unilateral changes by Roland François> McGrath introducing the BROKEN_BROKET define, or something François> like that, and all the doing it later took to clean this François> out.) I understand. François> Python (the distribution, which is what is in question here) François> does not use any of our `lib/' things, it is not going to François> use them, and it is not going to provide new such modules, François> so the distribution includes `config.h' everywhere, by François> permanent choice, without any need to use `HAVE_CONFIG_H' to François> decide if that inclusion is needed or not. So, even François> `-DHAVE_CONFIG_H' is useless `make' clutter in this case, François> and that's why the Python packagers wanted to get rid of it. François> In fact, in practice `-DHAVE_CONFIG_H' is only needed for François> packages using those common `lib/' modules, but many François> packages do not. Now that Autoconf is used with projects François> who have a life outside GNU, this is less necessary. Guido François> found, and got me to remember, that `@DEFS@' is the culprit: François> people just do not have to use it in their hand-crafted François> Makefiles, which is the case for Python. For away-from-GNU François> packages using Automake, some Automake option might exist so François> `@DEFS@' does not get generated? The only goal here is to François> get a cleaner `make' output. I understand the goal, but much of the effort is devoted to having the thing work cleanly, not being beautiful. Another goal is to have it being easy to maintain, i.e., not having too much to document, too much to support, too much to test etc. So, although I don't know what the Automake team might think of this idea, I suspect they'll want to focus on other features :(
I'm not sure I completely understand the question here: if HAVE_CONFIG_H is specified, it means config.h is created. So if you use a config.h, why does it matter not to define HAVE_CONFIG_H?
It's just clutter on the command line that we don't need. But never mind, I found a way to lose it already. --Guido van Rossum (home page: http://www.python.org/~guido/)
[Guido van Rossum]
Since we don't use this idiom, we can safely remove the -DHAVE_CONFIG_H (if we can find where it is set).
I guess you will have to override some `m4' macro within `configure.in', or related machinery. If things did not change too much, this probably means diving into `acgeneral.m4', to find out how and where this is best done. -- François Pinard http://www.iro.umontreal.ca/~pinard
Since we don't use this idiom, we can safely remove the -DHAVE_CONFIG_H (if we can find where it is set).
I guess you will have to override some `m4' macro within `configure.in', or related machinery. If things did not change too much, this probably means diving into `acgeneral.m4', to find out how and where this is best done.
I haven't the guts. Would you mind sending a patch? --Guido van Rossum (home page: http://www.python.org/~guido/)
Since we don't use this idiom, we can safely remove the -DHAVE_CONFIG_H (if we can find where it is set).
I guess you will have to override some `m4' macro within `configure.in', or related machinery. If things did not change too much, this probably means diving into `acgeneral.m4', to find out how and where this is best done.
I haven't the guts. Would you mind sending a patch?
Never mind. Getting rid of DEFS from Makefile.pre.in did the trick. --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (6)
-
Akim Demaille -
Guido van Rossum -
Jack Jansen -
M.-A. Lemburg -
martin＠v.loewis.de -
pinard＠iro.umontreal.ca