pyconfig.h not regenerated by "config.status --recheck"
I decided to investigate why the resource module wasn't getting built on my Mac today. A quick check showed that build.opt/pyconfig.h didn't include this stanza: /* Define if you have the 'getpagesize' function. */ #define HAVE_GETPAGESIZE 1 although pyconfig.h.in contained this stanza: /* Define if you have the 'getpagesize' function. */ #undef HAVE_GETPAGESIZE The date on pyconfig.h.in was May 5. The date on build.opt/pyconfig.h was Feb 27. Executing ./config.status --recheck in my build.opt tree doesn't regenerate pyconfig.h. I then tried executing ../configure --prefix=/Users/skip/local This generated pyconfig.h. It would thus appear that config.status shouldn't be used by developers. Apparently one of the other flags it appends to the generated configure command suppresses generation of pyconfig.h (and maybe other files). Skip
Skip Montanaro
This generated pyconfig.h. It would thus appear that config.status shouldn't be used by developers. Apparently one of the other flags it appends to the generated configure command suppresses generation of pyconfig.h (and maybe other files).
Can you find out whether this is related to the fact that you are building in a separate build directory? Regards, Martin
>> This generated pyconfig.h. It would thus appear that config.status >> shouldn't be used by developers. Apparently one of the other flags >> it appends to the generated configure command suppresses generation >> of pyconfig.h (and maybe other files). Martin> Can you find out whether this is related to the fact that you Martin> are building in a separate build directory? I just confirmed that it's not related to the separate build directory. When you run config.status --recheck it reruns your latest configure command with the extra flags --no-create and --no-recursion. Without rummaging around in the configure file my guess is the --no-create flag is the culprit. So, a word to the wise: avoid config.status --recheck. Skip
On Tue, May 6 2003 Skip Montanaro wrote:
>> This generated pyconfig.h. It would thus appear that config.status >> shouldn't be used by developers. Apparently one of the other flags >> it appends to the generated configure command suppresses generation >> of pyconfig.h (and maybe other files).
Martin> Can you find out whether this is related to the fact that you Martin> are building in a separate build directory?
I just confirmed that it's not related to the separate build directory. When you run config.status --recheck it reruns your latest configure command with the extra flags --no-create and --no-recursion. Without rummaging around in the configure file my guess is the --no-create flag is the culprit.
So, a word to the wise: avoid config.status --recheck.
I don't agree. Just run ./config.status without arguments after running
./config.status --recheck. That *will* regenerate all files.
-- Sjoerd Mullender
Skip Montanaro
So, a word to the wise: avoid config.status --recheck.
I don't know if I'm wise or not but I do tend to go for rm -rf build && mkdir build && cd build && ../configure -q && make -s for most rebuilds... I guess I should trust my tools a bit more. Cheers, M. -- The meaning of "brunch" is as yet undefined. -- Simon Booth, ucam.chat
>> So, a word to the wise: avoid config.status --recheck. Michael> I don't know if I'm wise or not but I do tend to go for Michael> rm -rf build && mkdir build && cd build && ../configure -q && make -s Michael> for most rebuilds... I guess I should trust my tools a bit Michael> more. I got in the habit of using config.status --recheck because it allowed me to only remember a single configure-like command for most packages I build/install using configure. I only had to figure out what flags to pass to configure once, then later typing "C-r rech" in bash was sufficient to reconfigure the package. It would be nice if config.status had a flag which actually executed configure without the --no-create and --no-recursion flags. Someone mentioned invoking config.status without the --recheck flag. I don't think that's wise in a development environment since that doesn't actually run configure. Since we're talking about building Python in a development environment, I find it hard to believe you'd want to skip configure altogether. Skip
On Wed, May 7 2003 Skip Montanaro wrote:
>> So, a word to the wise: avoid config.status --recheck.
Michael> I don't know if I'm wise or not but I do tend to go for
Michael> rm -rf build && mkdir build && cd build && ../configure -q && make -s
Michael> for most rebuilds... I guess I should trust my tools a bit Michael> more.
I got in the habit of using config.status --recheck because it allowed me to only remember a single configure-like command for most packages I build/install using configure. I only had to figure out what flags to pass to configure once, then later typing "C-r rech" in bash was sufficient to reconfigure the package. It would be nice if config.status had a flag which actually executed configure without the --no-create and --no-recursion flags.
Someone mentioned invoking config.status without the --recheck flag. I don't think that's wise in a development environment since that doesn't actually run configure. Since we're talking about building Python in a development environment, I find it hard to believe you'd want to skip configure altogether.
I mentioned that. But I also said to do that after running with the
--recheck flag.
In fact, I use the bit
Makefile: Makefile.in config.h.in config.status
./config.status
config.status: configure
./config.status --recheck
in some of my makefiles. I just type "make Makefile" and it does all it
needs to do.
-- Sjoerd Mullender
participants (4)
-
martin＠v.loewis.de -
Michael Hudson -
Sjoerd Mullender -
Skip Montanaro