58804 - Allowing NSPR autoconf to build in srcdir

Status: RESOLVED FIXED

(NSPR :: NSPR, defect, P1)

Description

[cls]

Our biggest problem with allowing autoconf builds in the srcdir has been the
worry of clobbering the classic build's Makefile and potentially an accidental
check in of those generated files.  We can work around that problem by taking
advantage of a GNU make feature and start generating GNUmakefile(s) instead of
Makefile(s).  GNU make looks for GNUmakefile(s) before Makefile(s) so there
should be no danger of an autoconf build using the wrong Makefile.  To make the
build stay clean, I'd like to rename the Makefile.in(s) to GNUmakefile.in(s).
Otherwise, we'll be generating GNUmakefile(s) from Makefile.in(s), which, while
easily doable, might confuse people.

Comment 1

[Wan-Teh Chang]

Although this is a clever trick, I think this will
confuse people because not everyone is aware of this
GNUmakefile->Makefile->makefile search order of GNU
make.

Unless we abandon the "classic" build system, I think
we just have to live with the limitation that autoconf
cannot be run in the source tree.

Comment 2

[cls]

Ok, I can live with that.  (abandoning the classic build system, that is) ;-)

Seriously, how are users going to be more confused by the presence of
GNUmakefile.in & Makefile than they are Makefile & Makefile.in?  The only people
who will see GNUmakefile, GNUmakefile.in & Makefile are those who actually use
the autoconf build system.  GNU make is already required so they shouldn't even
concern themselves with the GNUmakefiles unless they are going to work on them,
at which point, I would hope they knew a bit about them first. :)

The alternative to moving to replace the srcdir check with a warning stating the
consequences of building in the srcdir. I know of some users that are removing
the test themselves already.  Short of clobbering the existing build files,
there's no reason why they should not be able to do that given that they
understand the consequences.

Comment 3

[cls]

Feh.  s/to moving to/to moving the Makefiles is to/

Comment 4

[cls]

Per our meeting last week, I spent some time today getting win32 builds working
with the autoconf setup.  I wrote a skeleton configure.pl script that has
hardcoded win32 values and let it loose on the build.  After syncing up some
Makefile->Makefile.in differences I missed over the past year, the changes
needed to get win32 builds working from the generated files were fairly small.

Now, having done that, I think the perl script is overkill for what it does.
The current configure shell script works on win32.  It has 2 main problems:

1) Requires cygwin ash or bash.  shmsdos.exe isn't enough
2) Needs to be enhanced to contain all of the win32 settings

Using ash just for the configure script has the downside of pulling in an
additional build tool dependency, but it would be cleaner than maintaining both
scripts.  There is some slowdown associated with shell script. The default shell
script takes 14 secs to complete; 11 of which is generating the Makefiles.  The
perl script takes 0.30 secs.  The perl script also contains the Makefile
substitution optimizations.  Without those optimizations, it takes 4.76 secs.

Testing was done under Win2k, using cygwin 1.1.6, ash-20001012 & activestate
perl 522.  Some of the following cygwin utils may also be required:
autoconf, fileutils, findutils, gawk, grep, less, m4, patch, sed, shellutils,
textutils

Comment 5

[cls]

Attachment: Changes required for win32 autoconf builds

Comment 6

[cls]

Attachment: Configure perl script

Comment 7

[cls]

I have checked in the win32 autoconf changes patch (into client branch & trunk)
along with some other tweaks to make objdir builds work.  Here's an updated
configure.pl that understands objdirs.

Comment 8

[cls]

Attachment: Updated objdir-aware configure.pl

Comment 9

[cls]

I decided to make the win32 build work from the configure shell script so I can
see exactly how much slower of a build (due to the posix layer) we are talking
about.  In both cases, the build was configured using:
	sh ..\configure i386-cygwin32 --enable-optimize --disable-debug

Using Netscape's gmake 3.74 that uses shmsdos, the build took 1 min 8 sec.
Using cygwin's make 3.79.1 with whatever shell it picked by default (should be
sh), the build took 1 min 14 sec.
Using cygwin's make 3.79.1 specifying SHELL=sh (ash), the build took 1 min 17 secs.

Comment 10

[cls]

Attachment: Make configure.in win32 aware

Comment 11

[cls]

Attachment: Updated win32-enabled patch against NSPR trunk

Comment 12

[cls]

After some email conversations with wtc, it was decided to go ahead and add
win32 to the existing configure shell script and reserve the perl script for
platforms that have single configurations or have a pressing need to avoid the
shell script.  This means that win32 builds will require a bourne compatible
shell as well as a handful of unix utilities used in a typical configure script:
sed, awk, grep, cmp.  I modified the shell script so that most of the checks are
disabled when building for win32 and attempted to make it smart enough to
realize when you want to build with msvc even though config.guess returns cygwin.

The patch is against the NSPR trunk.

Comment 13

[timeless]

[lib] /MACHINE:{ALPHA|ARM|IX86|MIPS|MIPS16|MIPSR41XX|PPC|SH3|SH4}
we don't care...
these improvements will set the borland 
(cl,link,lib,rc)=>(bcc32,ilink32,tlib,brc32) port back a bit, so i'll attach a 
patch diff -w.

this looked wierd:
AR='lib -NOLOGO -OUT:"$@"'
AR_FLAGS=

Comment 14

[timeless]

Attachment: erm, too lazy to diff.

Comment 15

[cls]

Attach 21768 has been checked into the client branch and the tip.

Comment 16

[Wan-Teh Chang]

Chris, this bug is fixed, right?

Could you also remove the Makefile's from the tip
of NSPR?  We need to make sure that the tip has
all the checkins.  Thanks.

Comment 17

[cls]

Yes, this bug is fixed.  I was waiting until the dust settled before I removed
the Makefiles from the tip.  It looks like most of the remaining problems
associated with the switchover are just tool compatibility issues not
necessarily problems with the build system itself.  Marking fixed.