13.37 KB, patch
|Details | Diff | Splinter Review|
11.60 KB, patch
|Details | Diff | Splinter Review|
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
Changed the target milestone to m11. If M11 is the first beta release, we should support as many build combinations as possible.
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.
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.
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?
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.
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
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?
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.
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
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
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.
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.
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?
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Yes, it can. Thanks for your help.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.