Closed Bug 58804 Opened 19 years ago Closed 19 years ago

Allowing NSPR autoconf to build in srcdir

Categories

(NSPR :: NSPR, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: cls, Assigned: wtc)

References

Details

Attachments

(6 files)

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.
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.
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.

Feh.  s/to moving to/to moving the Makefiles is to/
Status: NEW → ASSIGNED
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

Attached file Configure perl script
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.
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.

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.
[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=
Keywords: approval, patch, review
OS: Linux → All
Attach 21768 has been checked into the client branch and the tip.
Blocks: 58981
Priority: P3 → P1
Target Milestone: --- → 4.2
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.
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.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.