Makefile incorrect for make -j

[p5pRT]

Migrated from rt.perl.org#121587 (status was 'rejected')

Searchable as RT121587$

[p5pRT]

From perl-diddler@tlinx.org

Created by perl-diddler@tlinx.org

I usually try doing a 'make -j' when I do a make and on subsequent invocations\, scale it back if the load gets high enough to cause thrashing. Example '-j 16' is more efficient in generating the linux kernel and saves 15-20 (or more) seconds off a 3 minute build. Have seen the load go over 100 if I don't restrain it...but it keeps on going\, and finishes though perhaps a bit more slowly when 'restrained'...

perlbuild\, OTOH\, doesn't seem to be parallel make safe.

It will build if I don't use -j\, but fail with it.

Seems it the earliest error I see in the make is​:

In file included from cop.h​:381​:0\,   from perl.h​:3446\,   from miniperlmain.c​:40​: mydtrace.h​:14​:26​: fatal error​: perldtrace.h​: No such file or directory # include "perldtrace.h"

--- Then there are bunch more errors with that message. Also failing is the target 'mydtrace.h' (because of perldtrace.h missing).

It seems to be building a bunch of ".o" files that depend on it\, but ino perldtrace.h. Is that file created by miniperl? I ask because miniperl isn't done being created yet.

If you want\, I can attach a makefile\, but I would guess the a standard makefile w/dtrace would reproduce it.

BTW -- any chance of make test becoming parallel safe? I seem to remember it uses some separate mechanism that I can never remember w/o searching for it... would be nice if it just could use the standard make flags.

Perl Info

``` Flags: category=core severity=medium Site configuration information for perl 5.16.3: Configured by law at Wed Jan 22 12:58:58 PST 2014. Summary of my perl5 (revision 5 version 16 subversion 3) configuration: Platform: osname=linux, osvers=3.12.0-isht-van, archname=x86_64-linux-thread-multi-ld uname='linux ishtar 3.12.0-isht-van #1 smp preempt wed nov 13 16:50:51 pst 2013 x86_64 x86_64 x86_64 gnulinux ' config_args='' hint=previous, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=define usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-g -O2', cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' ccversion='', gccversion='4.8.1 20130909 [gcc-4_8-branch revision 202388]', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='long double', nvsize=16, Off_t='off_t', lseeksize=8 alignbytes=16, prototype=define Linker and Libraries: ld='gcc', ldflags ='-g -fstack-protector -fPIC' libpth=/usr/lib64 /lib64 libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc -lgdbm_compat perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc libc=/lib/libc-2.18.so, so=so, useshrplib=true, libperl=libperl-5.16.3.so gnulibc_version='2.18' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/home/perl/perl-5.16.3/lib/x86_64-linux-thread-multi-ld/CORE' cccdlflags='-fPIC', lddlflags='-shared -g -O2 -fstack-protector -fPIC' Locally applied patches: @INC for perl 5.16.3: /home/perl/perl-5.16.3/lib/site/x86_64-linux-thread-multi-ld /home/perl/perl-5.16.3/lib/site /home/perl/perl-5.16.3/lib/x86_64-linux-thread-multi-ld /home/perl/perl-5.16.3/lib . Environment for perl 5.16.3: HOME=/home/law LANG=en_US.utf8 LANGUAGE (unset) LC_COLLATE=C LC_CTYPE=en_US.utf8 LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/home/law/bin/lib:/sbin:/home/law/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:.:/usr/lib/qt3/bin:/opt/dell/srvadmin/bin:/usr/sbin:/etc/local/func_lib:/home/law/lib PERL_BADLANG (unset) SHELL=/bin/bash ```

[p5pRT]

From @tonycoz

On Sun\, Apr 06\, 2014 at 02​:34​:34PM -0700\, Linda Walsh wrote​:

[Please describe your issue here] I usually try doing a 'make -j' when I do a make and on subsequent invocations\, scale it back if the load gets high enough to cause thrashing. Example '-j 16' is more efficient in generating the linux kernel and saves 15-20 (or more) seconds off a 3 minute build. Have seen the load go over 100 if I don't restrain it...but it keeps on going\, and finishes though perhaps a bit more slowly when 'restrained'...

perlbuild\, OTOH\, doesn't seem to be parallel make safe.

It will build if I don't use -j\, but fail with it.

Seems it the earliest error I see in the make is​:

In file included from cop.h​:381​:0\, from perl.h​:3446\, from miniperlmain.c​:40​: mydtrace.h​:14​:26​: fatal error​: perldtrace.h​: No such file or directory # include "perldtrace.h"

--- Then there are bunch more errors with that message. Also failing is the target 'mydtrace.h' (because of perldtrace.h missing).

It seems to be building a bunch of ".o" files that depend on it\, but ino perldtrace.h. Is that file created by miniperl? I ask because miniperl isn't done being created yet.

If you want\, I can attach a makefile\, but I would guess the a standard makefile w/dtrace would reproduce it.

This looks like a duplicate of #120120\, which I've responded to\, but haven't received any further responses to.

The makedepend step should make each object depend on mydtrace.h\, and mydtrace.h should have an explicit dependency generated on perldtrace.h.

If you aren't getting those dependencies then I'd like to see your Makefile and config.sh (and makefile.)

I normally do parallel builds of perl\, as do other porters.[1]

BTW -- any chance of make test becoming parallel safe? I seem to remember it uses some separate mechanism that I can never remember w/o searching for it... would be nice if it just could use the standard make flags.

As to parallel testing\, I assume you want​:

  make -j8 test

to perform the tests in parallel. The problem with that is the output of commands run by make is sent to the current tty\, but otherwise discarded\, while for tests we want to parse that output to produce the summary you see from make test or make test_harness.

So to get parallel testing we need to implement it ourselves\, and it's trvially invoked with​:

  TEST_JOBS=8 make test_harness

Tony

[1] except for the poor Win32 users

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From perl-diddler@tlinx.org

On Sun Apr 06 15​:12​:25 2014\, tonyc wrote​:

This looks like a duplicate of #120120\, which I've responded to\, but haven't received any further responses to.

---

Dunno... might be.

The makedepend step should make each object depend on mydtrace.h\, and mydtrace.h should have an explicit dependency generated on perldtrace.h.

I deleted makedepend to see if it would rebuild again...

ahh.. It seems that the objs start getting build before makedepend finishes. If I do a separate makedepend 1st\, then the make -j seems to start off ok (didn't let it finish\, but it was compiling things with dtrace).

Something in the makefile isn't waiting on the makedepend to complete before going on.

Where's the deps on makedepend suppose to be?

Also\, if something deps on make depend (but not what it makes)\, as soon as the makedepend file is created\, everything else goes -- but does 'makedepend' need to run before everything else goes?

If you aren't getting those dependencies then I'd like to see your Makefile and config.sh (and makefile.)

---

  Not sure if I am or not...it is making the makedepend\, but the obj builds start before makedepend has been run -- I think that's the prob.

Maybe there's a dep on makedepend\, but not it's final output?

As to parallel testing\, I assume you want​:

make -j8 test

---

  Well\, best from a testing standpoing would be 'make -j test'\, just to 'further verify' that there are no time dependencies...;-)

 

to perform the tests in parallel. The problem with that is the output of commands run by make is sent to the current tty\, but otherwise discarded\, while for tests we want to parse that output to produce the summary you see from make test or make test_harness.

So to get parallel testing we need to implement it ourselves\, and it's trvially invoked with​:

---

  Anyway to catch the "-j" in the make invocation line and convert that into a single make with "TEST_JOBS=..." I've seen TEST_JOBS before\, (actually is IS set in my ENV to 12\, I just didn't remember the name or that I'd put it in my login ENV...). I don't remember details inside the kernel's ".config" either\, even though I build it more often than perl\, but they managed to "tuck" all the oddities into the standard framework.

[1] except for the poor Win32 users

---

Sigh...so dumped on they are...but win32 is hard! gimme *nix anyday.

[p5pRT]

From perl-diddler@tlinx.org

actually\, even if I do a separate "make depend" first\, then the make\, I still end up with​:

  Making x2p stuff LD_LIBRARY_PATH=/home/perl/perl-5.16.3 ./perl -f -Ilib pod/buildtoc -q make[1]​: Entering directory `/home/perl/perl-5.16.3/x2p' You haven't done a "make depend" yet! You haven't done a "make depend" yet! You haven't done a "make depend" yet! make[1]​: *** [hash.o] Error 1 make[1]​: *** Waiting for unfinished jobs.... make[1]​: *** [str.o] Error 1 make[1]​: *** [util.o] Error 1 You haven't done a "make depend" yet! make[1]​: *** [walk.o] Error 1 make[1]​: Leaving directory `/home/perl/perl-5.16.3/x2p' make​: *** [translators] Error 2 make​: *** Waiting for unfinished jobs.... Use of uninitialized value $_ in substitution (s///) at pod/buildtoc line 213\, \<$fh> chunk 2. Use of uninitialized value $_ in pattern match (m//) at pod/buildtoc line 214\, \<$fh> chunk 2. Use of uninitialized value $_ in substitution (s///) at pod/buildtoc line 217\, \<$fh> chunk 2. Use of uninitialized value $_ in substitution (s///) at pod/buildtoc line 217\, \<$fh> chunk 2. Use of uninitialized value $_ in substitution (s///) at pod/buildtoc line 213\, \<$fh> chunk 2. Use of uninitialized value $_ in pattern match (m//) at pod/buildtoc line 214\, \<$fh> chunk 2. Use of uninitialized value $_ in substitution (s///) at pod/buildtoc line 217\, \<$fh> chunk 2. Use of uninitialized value $_ in substitution (s///) at pod/buildtoc line 217\, \<$fh> chunk 2. Use of uninitialized value $_ in substitution (s///) at pod/buildtoc line 213\, \<$fh> chunk 2. Use of uninitialized value $_ in pattern match (m//) at pod/buildtoc line 214\, \<$fh> chunk 2. Use of uninitialized value $_ in substitution (s///) at pod/buildtoc line 217\, \<$fh> chunk 2. Use of uninitialized value $_ in substitution (s///) at pod/buildtoc line 217\, \<$fh> chunk 2.

---

remaking depend\, I see why\, but not sure what is causing it​:

make depend sh ./makedepend MAKE=make make[1]​: Entering directory `/home/perl/perl-5.16.3' /usr/bin/dtrace -h -s perldtrace.d -o perldtrace.h.in sed -e '/const/!s/char \*/const char */g' perldtrace.h.in >perldtrace.h rm -f perldtrace.h.in echo av.c scope.c op.c doop.c doio.c dump.c gv.c hv.c mg.c reentr.c mro.c perl.c perly.c pp.c pp_hot.c pp_ctl.c pp_sys.c regcomp.c regexec.c utf8.c sv.c taint.c toke.c util.c deb.c run.c universal.c pad.c globals.c keywords.c perlio.c perlapi.c numeric.c mathoms.c locale.c pp_pack.c pp_sort.c miniperlmain.c opmini.c perlmini.c perldtrace.h | tr ' ' '\n' >.clist make[1]​: Leaving directory `/home/perl/perl-5.16.3' Finding dependencies for av.o. Finding dependencies for scope.o. Finding dependencies for op.o. Finding dependencies for doop.o. Finding dependencies for doio.o. Finding dependencies for dump.o. Finding dependencies for gv.o. Finding dependencies for hv.o. Finding dependencies for mg.o. Finding dependencies for reentr.o. Finding dependencies for mro.o. Finding dependencies for perl.o. Finding dependencies for perly.o. Finding dependencies for pp.o. Finding dependencies for pp_hot.o. Finding dependencies for pp_ctl.o. Finding dependencies for pp_sys.o. Finding dependencies for regcomp.o. Finding dependencies for regexec.o. Finding dependencies for utf8.o. Finding dependencies for sv.o. Finding dependencies for taint.o. Finding dependencies for toke.o. Finding dependencies for util.o. Finding dependencies for deb.o. Finding dependencies for run.o. Finding dependencies for universal.o. Finding dependencies for pad.o. Finding dependencies for globals.o. Finding dependencies for keywords.o. Finding dependencies for perlio.o. Finding dependencies for perlapi.o. Finding dependencies for numeric.o. Finding dependencies for mathoms.o. Finding dependencies for locale.o. Finding dependencies for pp_pack.o. Finding dependencies for pp_sort.o. Finding dependencies for miniperlmain.o. Finding dependencies for opmini.o. Finding dependencies for perlmini.o. Finding dependencies for perlmini.o. make[1]​: Entering directory `/home/perl/perl-5.16.3' echo Makefile.SH cflags.SH config_h.SH makedepend.SH myconfig.SH pod/Makefile.SH | tr ' ' '\n' >.shlist make[1]​: Leaving directory `/home/perl/perl-5.16.3' Updating makefile... cd x2p; make depend make[1]​: Entering directory `/home/perl/perl-5.16.3/x2p' sh ../makedepend MAKE=make ../makedepend​: Already running\, exiting.

[p5pRT]

From @tonycoz

On Sun\, Apr 06\, 2014 at 03​:39​:45PM -0700\, Linda Walsh via RT wrote​:

On Sun Apr 06 15​:12​:25 2014\, tonyc wrote​:

This looks like a duplicate of #120120\, which I've responded to\, but haven't received any further responses to. --- Dunno... might be.

The makedepend step should make each object depend on mydtrace.h\, and mydtrace.h should have an explicit dependency generated on perldtrace.h.

I deleted makedepend to see if it would rebuild again...

ahh.. It seems that the objs start getting build before makedepend finishes. If I do a separate makedepend 1st\, then the make -j seems to start off ok (didn't let it finish\, but it was compiling things with dtrace).

Something in the makefile isn't waiting on the makedepend to complete before going on.

Where's the deps on makedepend suppose to be?

Also\, if something deps on make depend (but not what it makes)\, as soon as the makedepend file is created\, everything else goes -- but does 'makedepend' need to run before everything else goes?

Configure runs makedepend unless you tell it not to\, it should have already been run before you run make.

By default\, at the end of a Configure run you should see something like​:

Finding dependencies for universal.o. Finding dependencies for pad.o. Finding dependencies for globals.o. Finding dependencies for keywords.o. Finding dependencies for perlio.o. Finding dependencies for perlapi.o. Finding dependencies for numeric.o. Finding dependencies for mathoms.o. Finding dependencies for locale.o. Finding dependencies for pp_pack.o. Finding dependencies for pp_sort.o. Finding dependencies for caretx.o. Finding dependencies for miniperlmain.o. Finding dependencies for opmini.o. Finding dependencies for perlmini.o. Updating makefile... Now you must run 'make'.

If you compile perl5 on a different machine or from a different object directory\, copy the Policy.sh file from this object directory to the new one before you run Configure -- this will help you with most of the policy defaults.

which is output from makedepend.

If you run Configure interactively\, and choose not to run makedepend\, it will tell you​:

  You must run 'make depend' then 'make'.

If you aren't getting those dependencies then I'd like to see your Makefile and config.sh (and makefile.) ---- Not sure if I am or not...it is making the makedepend\, but the obj builds start before makedepend has been run -- I think that's the prob.

Maybe there's a dep on makedepend\, but not it's final output?

all depends on makefile which depends on Makefile and makedepend.

makedepend then depends on makedepend.SH and config.sh.

But this should only be a problem if you don't let Configure run makedepend\, or if you modify Makefile or config.sh manually after running Configure (in which case\, you should run "make depend".)

Tony

[p5pRT]

From perl-diddler@tlinx.org

On Sun Apr 06 16​:25​:17 2014\, tonyc wrote​:

Configure runs makedepend unless you tell it not to\, it should have already been run before you run make.

---

Even with doing a make depend first\, I still had the errors in x2p ???

But\, intially\, wanting to use my prior build\, but with a few changes\, I went to config.sh

In config.h it says​: # This file was produced by running the Configure script. It holds all the # definitions figured out by Configure. Should you modify one of these values\, # do not forget to propagate your changes by running "Configure -der". You may # instead choose to run each of the .SH files by yourself\, or "Configure -S".

---

So I ran Configure -der only to have that overwrite all my changes in config.h. Grrr. Configure -d says take defaults -- which isn't what config.sh had in it. So got a backup of my config.sh\, did it again but this time by running "Configure -S". It seems like the instructions to run "-der" don't propagate changes but delete them. Neither do the instructions to run Configure -S say anything about running my needing to manually run "make depend" after a "Configure -S".

But even after that and running make depend and seeing the finding deps -- running "make -j" still had the error in x2p noted above. It HAD built miniperl at that point .. and HAD done the finding deps as you mention. But for some reason\, x2p was confused.

I don't think "make clean" will clean out a "make .depending" in the main dir\, is there some place x2p needs cleaned as well?

But this should only be a problem if you don't let Configure run makedepend\, or if you modify Makefile or config.sh manually after running Configure (in which case\, you should run "make depend".)

---

  I did .. as I mentioned x2p gave a confused message about make depend not being run -- and when I run make depend\, it seemed that x2p's make-depend didn't run (a message about it already running?)\, but I didn't see that message in x2p's Makefile -- only in the toplevel makefile... so not sure why I'm getting that message out of the x2p subdir.

[p5pRT]

From perl-diddler@tlinx.org

BTW -- FWIW\, I find running Configure from scratch VERY error prone\, because 1) no way for me to skip to the part I want to change\, 2) requires too much attention 3) has no way to go back if you notice a type-o (other than restart).

I'm really the type that puts all my config in 1 shell file\, then runs that.

To setup all the default dirs for 'configure'\, I just set the package name and include a 'config.include'\, that sets most defaults\, the I include package-specific stuff or overrides after that.

So to do a new gen for a new tool​: -------------xrdp-config.sh----- #!/bin/bash

prg=xrdp prefix=/usr

. /home/tools/config.include

gen_config_ops

declare -a enables=( freerdp1) declare -a withs=( pic gnu-ld )

export LDFLAGS="-flto -fpie "

for ena in "${enables[@​]}" ; do   config_ops+="--enable-$ena " done

for withs in "${withs[@​]}" ; do   config_ops+="--with-$withs " done

configure $config_ops #make -j

---

That's a simple config. Squid and samba require alot more enable/ disable/with/without (36 & 31) lines\, but follow the same basic pattern.

Then config changes are done once in a script and I just rerun that. If the config is short\, I'll tell it to go and make as well.

for CFLAGS\, I try to run the linker's optimizer as well (-flto)\, but run all of -g + -O2 + all the 'O3' flags that don't involve some random increase in size (some of the O3 options can make a program slower because things won't fit in cache as well\, so I go with O2+the other ops that don't increase space or have minimal effect on it.

That usually yields about 5% over a stock -O2 (plus or minus).

I haven't created a perl with my own optimize ops\, so I don't really know if it will help or not (was one of the changes I put in this config.sh) -- that and moving the perl man sections to their own section (1p & 3p) along the lines of my distro -- since perl is a special case when it comes to following manpage guidelines\, and has copious amounts of documentation.

[p5pRT]

From [Unknown Contact. See original ticket]

BTW -- FWIW\, I find running Configure from scratch VERY error prone\, because 1) no way for me to skip to the part I want to change\, 2) requires too much attention 3) has no way to go back if you notice a type-o (other than restart).

I'm really the type that puts all my config in 1 shell file\, then runs that.

To setup all the default dirs for 'configure'\, I just set the package name and include a 'config.include'\, that sets most defaults\, the I include package-specific stuff or overrides after that.

So to do a new gen for a new tool​: -------------xrdp-config.sh----- #!/bin/bash

prg=xrdp prefix=/usr

. /home/tools/config.include

gen_config_ops

declare -a enables=( freerdp1) declare -a withs=( pic gnu-ld )

export LDFLAGS="-flto -fpie "

for ena in "${enables[@​]}" ; do   config_ops+="--enable-$ena " done

for withs in "${withs[@​]}" ; do   config_ops+="--with-$withs " done

configure $config_ops #make -j

---

That's a simple config. Squid and samba require alot more enable/ disable/with/without (36 & 31) lines\, but follow the same basic pattern.

Then config changes are done once in a script and I just rerun that. If the config is short\, I'll tell it to go and make as well.

for CFLAGS\, I try to run the linker's optimizer as well (-flto)\, but run all of -g + -O2 + all the 'O3' flags that don't involve some random increase in size (some of the O3 options can make a program slower because things won't fit in cache as well\, so I go with O2+the other ops that don't increase space or have minimal effect on it.

That usually yields about 5% over a stock -O2 (plus or minus).

I haven't created a perl with my own optimize ops\, so I don't really know if it will help or not (was one of the changes I put in this config.sh) -- that and moving the perl man sections to their own section (1p & 3p) along the lines of my distro -- since perl is a special case when it comes to following manpage guidelines\, and has copious amounts of documentation.

[p5pRT]

From perl-diddler@tlinx.org

On Sun Apr 06 18​:13​:29 2014\, LAWalsh wrote​:

BTW -- FWIW\, I find running Configure from scratch VERY error prone\,

---

To be specific\, by error-prone -- I mean I usually have to do it 3-4 time or more just to get what I meant to get (let alone trying any variations).

So I'm not saying it's bad -- just that I have a hard time getting through it correctly.

[p5pRT]

From @tux

On Sun\, 6 Apr 2014 21​:50​:55 -0700\, "Linda Walsh via RT" \perlbug\-followup@&#8203;perl\.org wrote​:

On Sun Apr 06 18​:13​:29 2014\, LAWalsh wrote​:

BTW -- FWIW\, I find running Configure from scratch VERY error prone\, ---- To be specific\, by error-prone -- I mean I usually have to do it 3-4 time or more just to get what I meant to get (let alone trying any variations).

So I'm not saying it's bad -- just that I have a hard time getting through it correctly.

Just a hunch​: did you "forget" to remove Policy.sh and config.sh from previous runs? If Configure finds these\, re-running Configure will for sure be able to do weird things. "Be able to" as it is a feature. You can build your own complicated Policy.sh and put it in place just before running Configure and set everything in there instead of from the command line. They are likely to conflict if you are not doing this on purpose

-- H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/ using perl5.00307 .. 5.19 porting perl5 on HP-UX\, AIX\, and openSUSE http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/ http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

[p5pRT]

From @tux

On Sun\, 6 Apr 2014 18​:13​:29 -0700\, "Linda Walsh via RT" \perlbug\-comment@&#8203;perl\.org wrote​:

BTW -- FWIW\, I find running Configure from scratch VERY error prone\, because 1) no way for me to skip to the part I want to change\,

Impossible to change\, as Configure is built out of 850+ units that might get re-arranged when something else changes (dependencies). Some code has to run before other code is run (setting up compiler flags for features required like threading\, using long doubles or 64bit integers

That gets even more complicated as Confiruge will "build" dynamic units that will be called later (callback units)

You can pre-fill all of the answers in Policy.sh

2) requires too much attention

Require the attention just *once*\, note everything that is *not* fitting the default answers and store that in Policy.sh. Then safe-keep Policy.sh and put it in place just before you run

# ./Configure -des

If any question is still answered not to your liking\, ammend Policy.sh and restart. I have not answered a question in Policy.sh for a looooong time now\, and my Policy.sh covers AIX\, HP-UX and Linux for all compiler configurations I test with

3) has no way to go back if you notice a type-o (other than restart).

Correct as you say\, but unless the question is answered wrong in such a way that it is influencing subsequent questions in the rest of the process\, Configure gives you an escape at the end to edit config.sh

That is not ideal\, but better than nothing

I'm really the type that puts all my config in 1 shell file\, then runs that.

Again\, better to put that work into building a well maintained Policy.sh

To setup all the default dirs for 'configure'\, I just set the package name and include a 'config.include'\, that sets most defaults\, the I include package-specific stuff or overrides after that.

So to do a new gen for a new tool​: -------------xrdp-config.sh----- #!/bin/bash

prg=xrdp prefix=/usr

. /home/tools/config.include

gen_config_ops

declare -a enables=( freerdp1) declare -a withs=( pic gnu-ld )

export LDFLAGS="-flto -fpie "

for ena in "${enables[@​]}" ; do config_ops+="--enable-$ena " done

for withs in "${withs[@​]}" ; do config_ops+="--with-$withs " done

configure $config_ops #make -j --------------------------------- That's a simple config. Squid and samba require alot more enable/ disable/with/without (36 & 31) lines\, but follow the same basic pattern.

Then config changes are done once in a script and I just rerun that. If the config is short\, I'll tell it to go and make as well.

for CFLAGS\, I try to run the linker's optimizer as well (-flto)\, but run all of -g + -O2 + all the 'O3' flags that don't involve some random increase in size (some of the O3 options can make a program slower because things won't fit in cache as well\, so I go with O2+the other ops that don't increase space or have minimal effect on it.

That usually yields about 5% over a stock -O2 (plus or minus).

I haven't created a perl with my own optimize ops\, so I don't really know if it will help or not (was one of the changes I put in this config.sh) -- that and moving the perl man sections to their own section (1p & 3p) along the lines of my distro -- since perl is a special case when it comes to following manpage guidelines\, and has copious amounts of documentation.

-- H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/ using perl5.00307 .. 5.19 porting perl5 on HP-UX\, AIX\, and openSUSE http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/ http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

[p5pRT]

From @doughera88

On Sun\, Apr 06\, 2014 at 05​:39​:50PM -0700\, "Linda Walsh via RT" wrote​:

On Sun Apr 06 16​:25​:17 2014\, tonyc wrote​:

Configure runs makedepend unless you tell it not to\, it should have already been run before you run make. ---- Even with doing a make depend first\, I still had the errors in x2p ???

But\, intially\, wanting to use my prior build\, but with a few changes\, I went to config.sh

In config.h it says​: # This file was produced by running the Configure script. It holds all the # definitions figured out by Configure. Should you modify one of these values\, # do not forget to propagate your changes by running "Configure -der". You may # instead choose to run each of the .SH files by yourself\, or "Configure -S". -----------

The reference to Configure -der is probably not helpful here. The preferred strategy is the one given in the INSTALL file​:

  =item Propagating your changes to config.sh

  If you make any changes to config.sh\, you should propagate   them to all the .SH files by running

  sh Configure -S

  You will then have to rebuild by running

  make depend   make

I would recommend we change the blurb at the top of config.sh to recommend 'Configure -S; make depend; make'. I would also recommend that we change the blurb that appears after running 'Configure -S' to explicity mention 'make depend'. (Offhand\, I'm not sure if that should be in Configure itself or in Makefile.SH.)

As far as 'Configure -der' is concerned\, it ought to work\, but I doubt anyone's tested it for years\, and its precise use case is rather subtle. The '-r' is supposed to avoid rerunning C library symbol extraction\, which used to be one of the most time-consuming elements of Configure. The overall command re-runs Configure\, accepting the current config.sh values as the defaults. If you hand-edit config.sh and then re-run Configure -der\, there are at least two ways in which that could change config.sh values. First\, the edited changes may be inconsistent with previously-probed values\, and hence the previous defaults may need to be overridden. Second\, there can be bugs in individual tests such that they don't properly respect a previous config.sh value.

I suspect that this re-running of Configure -der is very rarely done\, so there could well be bugs. If you really want to pursue those bugs\, we will need to see specific differences between the before and after config.sh files to follow up in any useful way. I also suspect it is possible to hand-edit config.sh such that no subsequent re-running of Configure -der will produce a workable configuration.

The better plan is usually to simply run Configure -S\, and that's what I'd suggest you do.

--   Andy Dougherty doughera@​lafayette.edu

[p5pRT]

From @doughera88

On Sun\, Apr 06\, 2014 at 05​:39​:50PM -0700\, "Linda Walsh via RT" wrote​:

On Sun Apr 06 16​:25​:17 2014\, tonyc wrote​:

Configure runs makedepend unless you tell it not to\, it should have already been run before you run make. ---- Even with doing a make depend first\, I still had the errors in x2p ???

It appears that something is not cleaning up properly\, but I can't reproduce your problem. Can you supply us with a minimal recipe to reproduce the problem from a clean source tree?

Thanks\,

--   Andy Dougherty doughera@​lafayette.edu

[p5pRT]

From perl-diddler@tlinx.org

On Mon Apr 07 05​:50​:09 2014\, doughera wrote​:

I suspect that this re-running of Configure -der is very rarely done\, so there could well be bugs. If you really want to pursue those bugs\, we will need to see specific differences between the before and after config.sh files to follow up in any useful way.

---

  Ha!... this one's easy... have the good\, and just rerun Configure -der.

  I can't guarantee is it messed up in the exact same way as it was before\, as after reading about the first 5 changes\, I realized it pretty much dumped them all. Also will attach policy.sh\, as some might think it was directing the show...

The better plan is usually to simply run Configure -S\, and that's what I'd suggest you do.

---

I wholeheartedly agree\, now that I know.... I was just following the instructions in config.sh...my bad.

Comments are notorious for being out of date.

But that said -- I can easily give you a before and after and a diff.

The output looks like it completely ditched my changes (changing compile ops and manpage locations) -- which should cause it to keel over and through out the whole thing.

FWIW -- I don't need this fixed\, BUT\, if it doesn't work\, might not want to document it as being of any use.

It changed byte alignment\, most all the flags\, my compile ops (thread+multiplicity)\, random number function\, library paths. Like it completely ignored config.sh and just went with a clean 'default' install...

Compressing the configs. will leave the diff (-U5) in text to make it easier to read\, and the policy.sh I stripped out the comments​: grep '^[^#].*$' Policy.sh

Your next request about showing how make clean isn't cleaning up a "clean source tree"\, seems a bit counterproductive.

The tree had errors multiple times. It quickly got into a situation where make clean wouldn't clean it and further attempts to build it run into probs -- even though make clean is run. That isn't something I would think should be 'normal'.

If I can show how make clean can't clean up a clean/pristine source tree\, that would be pretty amazing.

[p5pRT]

From perl-diddler@tlinx.org

Policy.stripped

[p5pRT]

From perl-diddler@tlinx.org

config.diff

[p5pRT]

From perl-diddler@tlinx.org

config.mangled.gz

[p5pRT]

From perl-diddler@tlinx.org

config.savegood.gz

[p5pRT]

From perl-diddler@tlinx.org

On Sun Apr 06 23​:09​:28 2014\, hmbrand wrote​:

On Sun\, 6 Apr 2014 18​:13​:29 -0700\, "Linda Walsh via RT" \perlbug\-comment@&#8203;perl\.org wrote​:

BTW -- FWIW\, I find running Configure from scratch VERY error prone\, because 1) no way for me to skip to the part I want to change\,

Impossible to change\, as Configure is built out of 850+ units that might get re-arranged when something else changes (dependencies). Some code has to run before other code is run (setting up compiler flags for features required like threading\, using long doubles or 64bit integers

---

  Hmm....*unconvinced look*. The linux kernel is at least 3-6x as complex so in addition to a serial\, non-random access interface that you can use but has similar features to configure -- no backing up for corrections\, but they also have a curses and 2 GUI interfaces that allow for 1 time setup (of course knowing which apply to your HW and which you want is another matter entirely!)...

That gets even more complicated as Confiruge will "build" dynamic units that will be called later (callback units)

You can pre-fill all of the answers in Policy.sh

---

??? Um -- confusion... I thought config.sh had all the details..??

where directories go\, what compiler flags to use\, what ldflags to use\, what to build....etc..Policy.sh didn't seem to be at that level of detail.

2) requires too much attention

Require the attention just *once*\, note everything that is *not* fitting the default answers and store that in Policy.sh. Then safe-keep Policy.sh and put it in place just before you run

---

  Lemme do it in an editor like gvim. I'm sure configure is as easy as cake\, **especially** for those who use it all the time. But for someone who builds (or rebuilds) a variety of tools\, it is consistently the most error prone -- for me.

As for your assertion\, only takes once.. I know on the kernel when a new version comes out I can 'make oldconfig'\, and it will show me all the new options and create an compat config with the same options as I had before with only delta's being in new stuff\, or less likely\, oldstuff removed.

I doubt there's a Configure-w-old-config option to upgrade things.

# ./Configure -des

If any question is still answered not to your liking\, ammend Policy.sh and restart. I have not answered a question in Policy.sh for a looooong time now\, and my Policy.sh covers AIX\, HP-UX and Linux for all compiler configurations I test with

---

Maybe policy.sh can have all the options that would go in config.sh\, and that would be the way to go... but what's the point of config.sh at that point -- i.e. I thought it was supposed to carry all the config details. ???

3) has no way to go back if you notice a type-o (other than restart).

Correct as you say\, but unless the question is answered wrong in such a way that it is influencing subsequent questions in the rest of the process\, Configure gives you an escape at the end to edit config.sh

That is not ideal\, but better than nothing

---

  If you know where to edit things. Seriously\, if I just used the make 'configure' in the kernel (the linear\, question interface)\, and made a mistake\, I'd have no clue where to look in the .config file for most of the options -- presuming I even remembered them.

  If a serial/linear interface was the only interface available to config the kernel\, there would be riots...neh\, people would have submitted to MS... ;-)

[p5pRT]

From @Leont

On Mon\, Apr 7\, 2014 at 4​:07 PM\, Linda Walsh via RT \< perlbug-followup@​perl.org> wrote​:

On Sun Apr 06 23​:09​:28 2014\, hmbrand wrote​:

On Sun\, 6 Apr 2014 18​:13​:29 -0700\, "Linda Walsh via RT" \perlbug\-comment@&#8203;perl\.org wrote​:

BTW -- FWIW\, I find running Configure from scratch VERY error prone\, because 1) no way for me to skip to the part I want to change\,

Impossible to change\, as Configure is built out of 850+ units that might get re-arranged when something else changes (dependencies). Some code has to run before other code is run (setting up compiler flags for features required like threading\, using long doubles or 64bit integers ---- Hmm....*unconvinced look*. The linux kernel is at least 3-6x as complex so in addition to a serial\, non-random access interface that you can use but has similar features to configure -- no backing up for corrections\, but they also have a curses and 2 GUI interfaces that allow for 1 time setup (of course knowing which apply to your HW and which you want is another matter entirely!)...

But Linux can actually depend on whole lot more things. Our configure has the restriction on having to work on any Unix with only the most minimal tools (basic bourne shell\, sed\, awk).

Linux' GUI interfaces to configuration are actually full-blown C programs. I'm sure it would be lovely to have something like that\, but I'm not sure it makes sense in our case.

I doubt there's a Configure-w-old-config option to upgrade things.

I thought Policy.sh could do just that\, but I may be wrong. It'd be a whole lot less useful for us anyway​: configuration options are a lot more stable for us\, we don't add commonly used configuration flags very often.

They have very different questions than we do. For us\, Configure is mostly about "what are the capabilities of this environment" and only a minority of "how should your perl work"\, whereas in Linux' case it's the other way around. Quite frankly\, I never run it without -de anyway. The few options I use can be easily passed via -D.

Leon

[p5pRT]

From @tux

On Mon\, 7 Apr 2014 07​:07​:33 -0700\, "Linda Walsh via RT" \perlbug\-followup@&#8203;perl\.org wrote​:

You can pre-fill all of the answers in Policy.sh
---- ??? Um -- confusion... I thought config.sh had all the details..??

where directories go\, what compiler flags to use\, what ldflags to use\, what to build....etc..Policy.sh didn't seem to be at that level of detail.

Policy.sh can be used to prepare all the default answers to Configure

Configure generates config.sh

config.sh will have *all* settings

Policy.sh will only define those that Configure would ask for or those you want to overrule as you do not agree with the defaults

# rm config.sh Policy.sh # cp ../Policy.sh . # sh ./Configure -des

-- H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/ using perl5.00307 .. 5.19 porting perl5 on HP-UX\, AIX\, and openSUSE http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/ http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

[p5pRT]

From @doughera88

On Mon\, Apr 07\, 2014 at 07​:00​:22AM -0700\, "Linda Walsh via RT" wrote​:

Your next request about showing how make clean isn't cleaning up a "clean source tree"\, seems a bit counterproductive.

I think you misunderstood. I asked for a "minimal recipe to reproduce the problem from a clean source tree". In more detail​: I wasn't able reproduce the problem\, and hence can't do anything about it. If\, however\, you were able to give me a recipe -- i.e. a set of instructions to follow -- starting from a clean source tree to reproduce the problem\, then I (or someone else) might be able to reproduce the problem and solve it. That recipe should be "minimal" in that it should involve the smallest number of non-default options and steps necessary to reproduce the problem.

--   Andy Dougherty doughera@​lafayette.edu

[p5pRT]

From perl-diddler@tlinx.org

On Mon Apr 07 09​:21​:01 2014\, doughera wrote​:

-- starting from a clean source tree to reproduce the problem\, then I (or someone else) might be able to reproduce the problem and solve it. That recipe should be "minimal" in that it should involve the smallest number of non-default options and steps necessary to reproduce the problem.

---

to get the problem of the x2p dir not building correctly\, go into a clean source dir\,

mkdir x2p/.depending

notice make depend won't run correctly and make clean won't clean it up.

Is that what you meant by simple that you couldn't reproduce?

Note\, having .depending in the top level dir won't get cleaned up either and will prevent a make from working.

But I already documented that\, so I'm sure you would be able to get to the root of that problem fairly easily?

[p5pRT]

From @doughera88

On Mon\, Apr 07\, 2014 at 10​:13​:13AM -0700\, "Linda Walsh via RT" wrote​:

On Mon Apr 07 09​:21​:01 2014\, doughera wrote​:

-- starting from a clean source tree to reproduce the problem\, then I (or someone else) might be able to reproduce the problem and solve it. That recipe should be "minimal" in that it should involve the smallest number of non-default options and steps necessary to reproduce the problem. --- to get the problem of the x2p dir not building correctly\, go into a clean source dir\,

mkdir x2p/.depending

Ok\, I see that symptom\, though I still don't know how that directory came to exist and not get deleted. It is normally created by makedepend and then deleted by makedepend. The fact that it was not is a problem with something somewhere\, but I don't know what or where. You haven't given me an easy way to reproduce the problem that results in the directory x2p/.depending existing.

If you are satisfied with fixing that symptom\, it's easy. See the following section in INSTALL

  =head1 Starting all over again

  If you wish to rebuild perl from the same build directory\, you should   clean it out with the command

  make distclean

  or

  make realclean

  The only difference between the two is that make distclean also removes   your old config.sh and Policy.sh files. (A plain 'make clean' will not   delete the makefiles used for rebuilding perl\, and will also not delete   a number of library and utility files extracted during the build process.)

  If you are upgrading from a previous version of perl\, or if you   change systems or compilers or make other significant changes\, or if   you are experiencing difficulties building perl\, you should not reuse   your old config.sh.

In short\, use 'make realclean' instead of 'make clean'.

--   Andy Dougherty doughera@​lafayette.edu

[p5pRT]

From @doughera88

On Mon\, Apr 07\, 2014 at 07​:00​:22AM -0700\, "Linda Walsh via RT" wrote​:

On Mon Apr 07 05​:50​:09 2014\, doughera wrote​:

I suspect that this re-running of Configure -der is very rarely done\, so there could well be bugs. If you really want to pursue those bugs\, we will need to see specific differences between the before and after config.sh files to follow up in any useful way. ---- Ha!... this one's easy... have the good\, and just rerun Configure -der.

I can't guarantee is it messed up in the exact same way as it was before\,

as after reading about the first 5 changes\, I realized it pretty much dumped them all. Also will attach policy.sh\, as some might think it was directing the show...

Ok\, this one is simple. The problem is that your old config.sh was not generated on exactly the same system as the new one.
Specifically\, the munged uname -a out for the old system is

  linux ishtar 3.12.0-isht-van #1 smp preempt wed nov 13 16​:50​:51 pst 2013 x86_64 x86_64 x86_64 gnulinux

while the current system you are trying to use is

  linux ishtar 3.13.7-isht-van #2 smp preempt thu mar 27 16​:11​:08 pdt 2014 x86_64 x86_64 x86_64 gnulinux

Configure detects that these two are not the same and therefore defaults to *not* loading up the old config.sh. Configure makes no attempt to parse the output of uname\, and has no way to judge whether the differences between systems are major or minor.

In short\, Configure is working as designed here\, and I don't see anything obvious to fix or change or even document differently. If you have a documentation patch to suggest that would have helped you avoid this difficultly\, then please send it along for consideration.

Thanks\,

--   Andy Dougherty doughera@​lafayette.edu

[p5pRT]

From perl-diddler@tlinx.org

On Mon Apr 07 17​:02​:45 2014\, doughera wrote​:

On Mon\, Apr 07\, 2014 at 10​:13​:13AM -0700\, "Linda Walsh via RT" wrote​:

On Mon Apr 07 09​:21​:01 2014\, doughera wrote​:

-- starting from a clean source tree to reproduce the problem\, then I (or someone else) might be able to reproduce the problem and solve it. That recipe should be "minimal" in that it should involve the smallest number of non-default options and steps necessary to reproduce the problem. --- to get the problem of the x2p dir not building correctly\, go into a clean source dir\,

mkdir x2p/.depending

Ok\, I see that symptom\, though I still don't know how that directory came to exist and not get deleted.

---

  I'm sure I interrupted a failing build. If I see 'error' or similar scroll by\, I might think the build is not going to work and want to investigate.

It is normally created by makedepend and then deleted by makedepend. The fact that it was not is a problem with something somewhere\, but I don't know what or where. You haven't given me an easy way to reproduce the problem that results in the directory x2p/.depending existing.

---

  But in this case\, I want the make process to be a bit more robust. I.e. -- if I do a "make clean"\, it should have cleaned that out -- Anything that would get in the way of me doing another "make". Note\, we are assuming I'm not changing any dependencies\, so that doesn't need redoing.

  Note​: "make clean" isn't behaving like one would normally expect it to -- more than once\, I've typed make clean only to watch it compile and build things in the process of cleaning(!?). Usually a make clean iterates over (and recurses into) the directories to clean out 'partial targets'.

If you are satisfied with fixing that symptom\, it's easy. See the following section in INSTALL

---

  Well now that I know what the problem is\, that one is fixed.

The only difference between the two is that make distclean also removes your old config.sh and Policy.sh files. (A plain 'make clean' will not delete the makefiles used for rebuilding perl\, and will also not delete a number of library and utility files extracted during the build process.)

---

  I was going to suggest that if I wanted to clean the deps\, either of those 'should' work.

If you are upgrading from a previous version of perl\, or if you change systems or compilers or make other significant changes\, or if you are experiencing difficulties building perl\, you should not reuse your old config.sh.

In short\, use 'make realclean' instead of 'make clean'.

---

  But I didn't want to rebuild dep (or at least I didn't know I did... ;-)).

[p5pRT]

From perl-diddler@tlinx.org

On Mon Apr 07 17​:29​:46 2014\, doughera wrote​:

On Mon\, Apr 07\, 2014 at 07​:00​:22AM -0700\, "Linda Walsh via RT" wrote​:

On Mon Apr 07 05​:50​:09 2014\, doughera wrote​:

I suspect that this re-running of Configure -der is very rarely done\, so there could well be bugs. If you really want to pursue those bugs\, we will need to see specific differences between the before and after config.sh files to follow up in any useful way. ---- Ha!... this one's easy... have the good\, and just rerun Configure -der.

I can't guarantee is it messed up in the exact same way as it was before\, as after reading about the first 5 changes\, I realized it pretty much dumped them all. Also will attach policy.sh\, as some might think it was directing the show...

Ok\, this one is simple. The problem is that your old config.sh was not generated on exactly the same system as the new one. Specifically\, the munged uname -a out for the old system is

linux ishtar 3.12.0-isht-van #1 smp preempt wed nov 13 16​:50​:51 pst 2013 x86_64 x86_64 x86_64 gnulinux

while the current system you are trying to use is

linux ishtar 3.13.7-isht-van #2 smp preempt thu mar 27 16​:11​:08 pdt 2014 x86_64 x86_64 x86_64 gnulinux

Configure detects that these two are not the same and therefore defaults to *not* loading up the old config.sh. Configure makes no attempt to parse the output of uname\, and has no way to judge whether the differences between systems are major or minor.

In short\, Configure is working as designed here.

---

  The Configure was mis-designed. I don't know any other build that throws away your old config because you updated your kernel.

  In this case\, maybe what is needed is a platform hint in policy.sh to only look at the major version of a linux kernel before throwing away all the settings. OR\, possibly a better(?) is to look at the old arch-specific *libc* and the new one. If they are the same\, don't throw away old stuff. On linux\, anyway\, one thing that isn't in that version info is the version of libc. That is much more likely to have an ABI change that might affect something.

  Why would it think I don't want the same perl options (threading\, mult\, wordsize...etc\, when they only thing that changed was a kernel version number? The kernel version doesn't go into the build-sys triplet\, so I'd argue it shouldn't be considered in a decision to throw away old config vals. "configure" (gnu)\, associates 1 set of build options to the osname-arch-runtime (Linux-x86_64-Gnu/Linux).

If you have a documentation patch to suggest that would have helped you avoid this difficultly\, then please send it along for consideration.

  I'd actually request documentation on why perl throws away all the choices based on a kernel version\, when everything else is the same? Is it documented why it does this? I don't know of any other project that does this. It may be that there are non-linux platforms were such makes a difference -- but if that is the case\, it seems that the arch-specific dirname should include the kernel-version if that is considered a reason to incompat all choices.

The general standard in this case looks at the the kernel-name\, (Linux)\, the hardware platform (x86_64) and the OS (Gnu/Linux). Perl's "archname" becomes a munge of the hw_kern+perl-build-ops. If *those* change\, then restarting a config _might_ be justified\, but I know of no situtation where the kernel make process wipes a users config file and replaces it with a platform default -- UNLESS the user explicitly tells it to.

As an example\, it has targets to disable non-loaded modules\, to include (statically link) loaded modules\, "defconfig" \<- arch default as well as several others. I won't assume that everyone here is familiar with the linux kernel build\, but if you have a linux tarball unwrapped\, at the top level you can type "make help" and will list available targets and what they do in a 100+ line help text.

[p5pRT]

From perl-diddler@tlinx.org

BTW -- (switching subjects to 'Makefile incorrect for make -j') -- if I start with a fresh source tree\, copy in my config.sh + policy.sh(needed?)\, then run​:

Configure -S make depend make -j

--- should that be something I could expect to work\, or are there other issues... (i.e. an orthogonal question\, apart from issues about when to ignore previous configs).

[p5pRT]

From [Unknown Contact. See original ticket]

BTW -- (switching subjects to 'Makefile incorrect for make -j') -- if I start with a fresh source tree\, copy in my config.sh + policy.sh(needed?)\, then run​:

Configure -S make depend make -j

--- should that be something I could expect to work\, or are there other issues... (i.e. an orthogonal question\, apart from issues about when to ignore previous configs).

[p5pRT]

From @tux

On Mon\, 7 Apr 2014 21​:13​:30 -0700\, "Linda Walsh via RT" \perlbug\-comment@&#8203;perl\.org wrote​:

BTW -- (switching subjects to 'Makefile incorrect for make -j') -- if I start with a fresh source tree\, copy in my config.sh + policy.sh(needed?)\,

If your Policy.sh (with a capital P) is well written\, you should NOT have to copy config.sh at all

then run​:

Configure -S make depend make -j

--- should that be something I could expect to work\, or are there other issues... (i.e. an orthogonal question\, apart from issues about when to ignore previous configs).

-- H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/ using perl5.00307 .. 5.19 porting perl5 on HP-UX\, AIX\, and openSUSE http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/ http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

[p5pRT]

From @doughera88

On Mon\, Apr 07\, 2014 at 09​:13​:30PM -0700\, "Linda Walsh via RT" wrote​:

BTW -- (switching subjects to 'Makefile incorrect for make -j') -- if I start with a fresh source tree\, copy in my config.sh + policy.sh(needed?)\, then run​:

Configure -S make depend make -j

--- should that be something I could expect to work\, or are there other issues... (i.e. an orthogonal question\, apart from issues about when to ignore previous configs).

It all depends on the content of your config.sh. Since config.sh can contain arbitrary shell statements\, there is no simple answer to your question. I do that sequence of steps all the time when testing out various patches to perl\, and it works just fine. However\, changes to perl's build system\, changes to config.sh\, or changes to my system could make it not work. There is no simple answer to your question.

Instead\, one recommended procedure for carrying build options from one version is to use Policy.sh\, as described in the INSTALL file and in Policy_sh.SH itself. Or\, if you prefer\, you may use a wrapper script that directly sets various Configure command-line flags. That works fine too.

--   Andy Dougherty doughera@​lafayette.edu

[p5pRT]

From @doughera88

On Mon\, Apr 07\, 2014 at 09​:03​:24PM -0700\, "Linda Walsh via RT" wrote​:

On Mon Apr 07 17​:29​:46 2014\, doughera wrote​:

Ok\, this one is simple. The problem is that your old config.sh was not generated on exactly the same system as the new one.

Configure detects that these two are not the same and therefore defaults to *not* loading up the old config.sh. Configure makes no attempt to parse the output of uname\, and has no way to judge whether the differences between systems are major or minor.

In short\, Configure is working as designed here. --- The Configure was mis-designed. I don't know any other build that throws away your old config because you updated your kernel.

I'm sorry it does not meet your expectations. Still\, you are welcome to continue using it anyway. Patches to improve it would be welcome.

--   Andy Dougherty doughera@​lafayette.edu

[p5pRT]

From @tux

On Mon\, 7 Apr 2014 21​:03​:24 -0700\, "Linda Walsh via RT" \perlbug\-followup@&#8203;perl\.org wrote​:

In short\, Configure is working as designed here.
--- The Configure was mis-designed. I don't know any other build that throws away your old config because you updated your kernel.

We did not design Configure ourselves

Configure is generated code using "dist"\, which is taken from svn​://svn.code.sf.net/p/dist/code/trunk/dist and amended for use of configuring Perl.

By the time that choice was made\, you probably know that perl is a lot older than many modern tools)\, this was the *only* tool that supports the wide range of operating systems and architectures that we so proudly support.

There have been attempts - by others - to replace Configure with tools like autogen/automake\, but they epically failed.

We agree that the way Configure works is somewhat sluggish and in some cases even annoying (like it not being to run faster or do parts in parallel)\, but that is the way it is and we have very little influence on that.

If you want new features for Configure that are beyond *our* scope of its usage\, like being able to skip all questions until a given point\, please raise that issue with the authors of dist.

Don't hold your breath in having those features immediately available in perl though\, as backporting changes in dist to the structure we use in Perl is massive. The last upgrade took us (me) three months.

I'm sorry we still use it if this puts you off loving perl\, but at the moment it is the best we have. I also think that most developers care more about the final result​: perl itself. The majority of the world's users of our favorite language will never even see or run Configure and they care more about a 3% speedup of the perl runtime than they do about a 75% speedup of Configure's runtime.

-- H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/ using perl5.00307 .. 5.19 porting perl5 on HP-UX\, AIX\, and openSUSE http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/ http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

[p5pRT]

From @jkeenan

No further discussion in six months. Closing ticket.

-- James E Keenan (jkeenan@​cpan.org)

[p5pRT]

@jkeenan - Status changed from 'open' to 'rejected'