11893 - Autoconf support in NSPR needed for X-compiling Mozilla

Status: VERIFIED FIXED

(NSPR :: NSPR, defect, P3)

Description

[cls]

This has been discussed before but I'm still interested in autoconf support for
NSPR.  The classic build system does not lend itself to cross-compiling easily
(if at all).  I've already filed a bug on the browser stating that we need
cross-compiling support (I believe QNX & OpenVMS depend upon it) but it is
dependent upon cross-compiling support in NSPR.  This is most easily done by
autoconf'ing NSPR.  On top of this, autoconf support makes it easier to port
NSPR to other platforms as well as centralize the configuration logic of NSPR
(in configure.in as opposed to various platform.mk).

The proof-of-concept work is already done and can be found in the
AUTOCONF_NSPR_WIN32_XCOMPILE_19990621_BRANCH branch.  An autoconf'd NSPR *does*
build under Win32 (using gcc) and the 2 test examples I ran worked.  I haven't
added detection for MSVC yet.  I used the UWIN development environment with egcs
1.1.2 when compiling natively.  I was also able to cross-compile from Linux to
Win32 using mingw32 and gcc 2.95.

Note, I'm not asking the NSPR group to switch to using autoconf exclusively nor
maintain two build systems.  I'm asking that they accept the patches and future
patches needed to keep the autoconf build system running.

http://cvs-mirror.mozilla.org/webtools/bonsai/cvsquery.cgi?treeid=default&module=all&branch=AUTOCONF_NSPR_WIN32_XCOMPILE_19990621_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=all&mindate=&maxdate=&cvsroot=%2Fcvsroot

Comment 1

[cls]

Changed the target milestone to m11.  If M11 is the first beta release, we
should support as many build combinations as possible.

Comment 2

[srinivas]

From looking at the modifications in the autoconf branch it appears that the
autoconf builds can be done with little effect on the current build system for
NSPR, is that right? We would like to see the autoconf build system to add to,
and not replace, the current build system.

If that is the goal, we can check in the autoconf stuff after the tree opens.

Comment 3

[cls]

Correct, the changes were made to have almost no effect on the classic build
system.
I cannot say how others will treat the classic vs autoconf build but the plan is
to replace the current multi-page hack needed to build NSPR in the tree from
Mozilla's configure.in with a simple autoconf call.  So by default, users
compiling Mozilla will be using the autoconf NSPR build not the classic NSPR
build.

Comment 4

[srinivas]

I have checked in the autoconf modifications on the NSPR tip. But, the checkins
for the following two files failed:

 nsprpub/config/Makefile.in
 nsprpub/config/autoconf.mk.in

with the following error

cvs server: cannot add file `autoconf.mk.in' when RCS file
`/cvsroot/mozilla/nsprpub/config/autoconf.mk.in,v' already exists
cvs [server aborted]: correct above errors first!

Does anyone know how to fix this?

Comment 5

[Daniel (Leaf) Nunes]

don't use cvs add. cvs commit is all you have to do when the file is already in
the repository. Give me a call at x3260 if you need help un-adding the files
you've added.

Comment 6

[cls]

Did you do a 'cvs add' or a 'cvs commit'?  All of the files should have already
been added onto the branch so you should only need to do a commit.

Also, the following files were missing:
nsprpub/build/autoconf/install-sh
nsprpub/build/autoconf/config.guess
nsprpub/build/autoconf/config.sub
nsprpub/pr/src/bthreads/Makefile.in
nsprpub/pr/src/cplus/Makefile.in
nsprpub/pr/src/cplus/tests/Makefile.in
nsprpub/pr/src/md/beos/Makefile.in

Comment 7

[Wan-Teh Chang]

I backed out the Windows resource file related stuff
from mozilla/nsprpub/config/rules.mk.  It has two problems:
1. The variable RESOBJ is not being used.  It has the same
   meaning as the existing variable RES.
2. $(RES) is added to OBJS twice on Win32.

Questions: do we need to keep the Makefile's and Makefile.in's
in sync?  Is there anything else between the autoconf and classic
build systems that we need to keep in sync?

Comment 8

[cls]

The Makefile.ins need to be kept in sync with the Makefiles.  Changes to
config/*.mk will need to be synchronized with configure.in & autoconf.mk.in.  I
imagine that the bulk of the initial sync patches will be to bring
configure.in/autoconf.mk.in up to the speed of config/*.mk.

Now, I was under the impression that the NSPR team would not be the ones keeping
the autoconf & classic builds in sync.  However since checkins to the NSPR
partition are restricted (last I checked), the NSPR team will need to approve
changes and checkins.

Comment 9

[srinivas]

I have checked in the missing files pointed out by Chris.

While most of the files exist in the repository, they are on a branch. The files
are also on the tip, but in 'dead' state, because the files were once added to
the tip and deleted. So, cvs requires 'add' followed by 'commit'; cvs commit by
itself will not work.

For the following two files I tried both commit and add-then-commit; both
failed.

config/Makefile.in
config/autoconk.mk.in

Comment 10

[cls]

Well, when I tried this command I got pass the ,v check but got nailed by the
NSPR partition permissions:
cvs -z3 ci -r HEAD -m "Initial versions" autoconf.mk.in Makefile.in

Comment 11

[cls]

Attachment: autoconf updates for the latest NSPR branch landing

Comment 12

[cls]

Attachment: previous sync + fixes in a regular diff (not cvs) format

Comment 13

[srinivas]

I get the following error with the cvs -z3 ci ...command

cvs server: Attempt to add reserved tag name HEAD
cvs server: could not stub branch HEAD for
/cvsroot/mozilla/nsprpub/config/autoconf.mk.in

If I run the command from the AUTOCONF branch, the command completes with no
error messages. But the file is not checked into the tip.

You can try to check in by unlokcing the partition.

Comment 14

[cls]

Ok, config/autoconf.mk.in & config/Makefile.in have been checked in.  Leaf had
to go into the repository and manually remove those files.  It wouldn't let me
checkin (after being given permission to the partition) because srivinas had a
lock on them.

Comment 15

[srinivas]

I noticed that the updates in attachement
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=2193
have been checked in.

Have these checkins been tested successfully? If so, can this bug be closed?

Comment 16

[cls]

Yes, it can.  Thanks for your help.

Comment 17

[cls]

Verified.