Starting next week the Mozilla build system is going to require python on all platforms. This will allow us to gradually convert various build scripts which are currently written in perl, and start hacking on an autoconf replacement written in python. Any python 2.3 or higher will be acceptable.
In addition, I have made a production release of MozillaBuild, version 1.0. The MozillaBuild package [1] is now the recommended build environment for all Mozilla developers on Windows. There were a few bugs with the 1.0 releases that have now been corrected in a MozillaBuild 1.1 release candidate [2].
After the Tinderboxes have been upgraded to use the MozillaBuild package on trunk, I am going to be discontinuing support for the cygwin build environment.
Benjamin Smedberg wrote: > After the Tinderboxes have been upgraded to use the MozillaBuild package on > trunk, I am going to be discontinuing support for the cygwin build environment.
Does msys still require Unix line breaks? This is a deal-breaker for me.
-- James Ross <sil...@warwickcompsoc.co.uk> ChatZilla and Venkman Developer
Benjamin Smedberg wrote: > Starting next week the Mozilla build system is going to require python on > all platforms. This will allow us to gradually convert various build scripts > which are currently written in perl, and start hacking on an autoconf > replacement written in python. Any python 2.3 or higher will be acceptable.
> In addition, I have made a production release of MozillaBuild, version 1.0. > The MozillaBuild package [1] is now the recommended build environment for > all Mozilla developers on Windows. There were a few bugs with the 1.0 > releases that have now been corrected in a MozillaBuild 1.1 release > candidate [2].
> After the Tinderboxes have been upgraded to use the MozillaBuild package on > trunk, I am going to be discontinuing support for the cygwin build environment.
> After the Tinderboxes have been upgraded to use the MozillaBuild package on > trunk, I am going to be discontinuing support for the cygwin build environment.
Does that mean one won't be able to build branches and trunk on the same machine as one requires cygwin and the other requires MozillaBuild/msys? Or can they be installed next to each other without problems?
Robert Kaiser wrote: > Benjamin Smedberg schrieb: >> After the Tinderboxes have been upgraded to use the MozillaBuild >> package on >> trunk, I am going to be discontinuing support for the cygwin build >> environment.
> Does that mean one won't be able to build branches and trunk on the same > machine as one requires cygwin and the other requires MozillaBuild/msys? > Or can they be installed next to each other without problems?
As documented on MDC, mozillabuild works with all of our active branches.
Alfred Peng wrote: > The MozillaBuild package is only available for Windows? Is there any > plan to provide it for Linux/Unix?
It is for Windows only, and I do not have any plans to make a unified package for other OSes. Most unix/linux systems come with all of our build prerequisites by default, or they can be easily obtained from a package manager or built from source; there is little value in a prepackaged build solution.
> Can we access the build scripts and deploy it for the contributed builds?
The tinderbox and patcher build scripts are all available in public CVS (mozilla/tools/tinderbox and mozilla/tools/release). There is admittedly not a lot of documentation for how they all fit together.
Benjamin Smedberg wrote: > After the Tinderboxes have been upgraded to use the MozillaBuild package on > trunk, I am going to be discontinuing support for the cygwin build environment.
Is it advisable or necessary to uninstall CygWin as part of this?
Alex Vincent wrote: > Benjamin Smedberg wrote: >> After the Tinderboxes have been upgraded to use the MozillaBuild >> package on >> trunk, I am going to be discontinuing support for the cygwin build >> environment.
> Is it advisable or necessary to uninstall CygWin as part of this?
It is unnecessary. You are of course welcome to uninstall all traces of cygwin after you make sure the new build system works.
Benjamin Smedberg wrote: > Starting next week the Mozilla build system is going to require python on > all platforms. This will allow us to gradually convert various build scripts > which are currently written in perl, and start hacking on an autoconf > replacement written in python. Any python 2.3 or higher will be acceptable.
> In addition, I have made a production release of MozillaBuild, version 1.0. > The MozillaBuild package [1] is now the recommended build environment for > all Mozilla developers on Windows. There were a few bugs with the 1.0 > releases that have now been corrected in a MozillaBuild 1.1 release > candidate [2].
> After the Tinderboxes have been upgraded to use the MozillaBuild package on > trunk, I am going to be discontinuing support for the cygwin build environment.
I have tried your MozillaBuildSetup-1.1 together with VC8 Express and its belonging SDK successfully, but I have made the following observations:
1. Now my build platform target identifies itself as i686-pc-mingw32 Is this correct? I thought Mingw is not really supported (?)
2. I have been unable to export the environmental variables MOZILLA_OFFICIAL=1 and BUILD_OFFICIAL=1 unless using mk_add_options in the .mozconfig. Using export inside the unix shell does not work, nor using SET in the start-msvc8.bat. 3. Finally I noticed that writing $PATH in the unix shell reports :/d/mozilla-build/moztools/bin: No such file or directory as the last entry in the path. I think this is a kind of a bug in MSYS as the moztools/bin really is found during the build.
Bengt-Erik Söderström wrote: > Benjamin Smedberg wrote: >> Starting next week the Mozilla build system is going to require python on >> all platforms. This will allow us to gradually convert various build >> scripts >> which are currently written in perl, and start hacking on an autoconf >> replacement written in python. Any python 2.3 or higher will be >> acceptable.
>> In addition, I have made a production release of MozillaBuild, version >> 1.0. >> The MozillaBuild package [1] is now the recommended build environment for >> all Mozilla developers on Windows. There were a few bugs with the 1.0 >> releases that have now been corrected in a MozillaBuild 1.1 release >> candidate [2].
>> After the Tinderboxes have been upgraded to use the MozillaBuild >> package on >> trunk, I am going to be discontinuing support for the cygwin build >> environment.
> I have tried your MozillaBuildSetup-1.1 together with VC8 Express and > its belonging SDK successfully, but I have made the following observations:
> 1. Now my build platform target identifies itself as i686-pc-mingw32 > Is this correct? I thought Mingw is not really supported (?)
> 2. I have been unable to export the environmental variables > MOZILLA_OFFICIAL=1 and BUILD_OFFICIAL=1 unless using mk_add_options in > the .mozconfig. > Using export inside the unix shell does not work, nor using SET in the > start-msvc8.bat. > 3. Finally I noticed that writing $PATH in the unix shell reports > :/d/mozilla-build/moztools/bin: No such file or directory as the last > entry in the path. I think this is a kind of a bug in MSYS as the > moztools/bin really is found during the build.
Benjamin Smedberg wrote: > After the Tinderboxes have been upgraded to use the MozillaBuild package on > trunk, I am going to be discontinuing support for the cygwin build environment.
Good move. Windows is slow enough already, Cygwin just made a bad situation worse. I've also made some fixes to MSYS recently that make it more usable as a development environment (e.g., better propagation of signals to native Windows apps). That made life a lot easier for us with our testing environment too. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/
Bengt-Erik Söderström wrote: > 1. Now my build platform target identifies itself as i686-pc-mingw32 > Is this correct? I thought Mingw is not really supported (?)
You are perhaps mistaking the mingw/msys *environment*, which is what the build package contains, with the mingw gcc *compiler*, which is not provided and is only marginally supported.
> 2. I have been unable to export the environmental variables > MOZILLA_OFFICIAL=1 and BUILD_OFFICIAL=1 unless using mk_add_options in > the .mozconfig. > Using export inside the unix shell does not work, nor using SET in the > start-msvc8.bat.
When did you set the variables. Please note that you have to set them before running configure. Changes to the environment after you run configure do not take effect inside our build system, because we cache the configure environment settings of those variables in autoconf.mk:
Benjamin Smedberg wrote: > Bengt-Erik Söderström wrote:
>> 1. Now my build platform target identifies itself as i686-pc-mingw32 >> Is this correct? I thought Mingw is not really supported (?)
> You are perhaps mistaking the mingw/msys *environment*, which is what the > build package contains, with the mingw gcc *compiler*, which is not provided > and is only marginally supported.
>> 2. I have been unable to export the environmental variables >> MOZILLA_OFFICIAL=1 and BUILD_OFFICIAL=1 unless using mk_add_options in >> the .mozconfig. >> Using export inside the unix shell does not work, nor using SET in the >> start-msvc8.bat.
> When did you set the variables. Please note that you have to set them before > running configure. Changes to the environment after you run configure do not > take effect inside our build system, because we cache the configure > environment settings of those variables in autoconf.mk:
That was probably the reason. Since then I wrote a small script which in the beginning exports the variables, cd to the right directory and finally make -f client.mk So now your package works like a charm. Thank you and keep up the good work!
I realize the Mozilla build process doesn't need or use this, but I have come to use it in my Verbosio project for getting snippets of code from other places. Can you help me figure out why this doesn't work in the MozillaBuild environment?
> I realize the Mozilla build process doesn't need or use this, but I have > come to use it in my Verbosio project for getting snippets of code from > other places. Can you help me figure out why this doesn't work in the > MozillaBuild environment?
I believe this is because the msys environment comes with an older version of cvs than 1.11.22. I'm not sure there's much you can do about it.
Benjamin Smedberg wrote: > Alex Vincent wrote: > I believe this is because the msys environment comes with an older version > of cvs than 1.11.22. I'm not sure there's much you can do about it.
Alex Vincent wrote: > Benjamin Smedberg wrote: >> Alex Vincent wrote: >> I believe this is because the msys environment comes with an older >> version >> of cvs than 1.11.22. I'm not sure there's much you can do about it.
> At present, I'm trying to figure out who could get that upgraded in the > msys side of things...
Earnie Boyd, the MSYS project lead, has gone on sabbatical, so that may take some time. It shouldn't be too hard to spin an updated cvs binary though. You might try asking on the msys-devel mailing list. I have commit rights there but it would be best to coordinate thru their mailing list. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/
Benjamin Smedberg wrote: > Bengt-Erik Söderström wrote:
>> 1. Now my build platform target identifies itself as i686-pc-mingw32 >> Is this correct? I thought Mingw is not really supported (?)
> You are perhaps mistaking the mingw/msys *environment*, which is what the > build package contains, with the mingw gcc *compiler*, which is not provided > and is only marginally supported.
>> 2. I have been unable to export the environmental variables >> MOZILLA_OFFICIAL=1 and BUILD_OFFICIAL=1 unless using mk_add_options in >> the .mozconfig. >> Using export inside the unix shell does not work, nor using SET in the >> start-msvc8.bat.
> When did you set the variables. Please note that you have to set them before > running configure. Changes to the environment after you run configure do not > take effect inside our build system, because we cache the configure > environment settings of those variables in autoconf.mk:
Sorry for my screw-ups earlier. I've got it working now, but I have one more observation:
In the beginning when configure is executing, it is issuing the command grep -P. This is not understood by the grep (version 2.4.2) included in the package. Later versions of grep (e.g cygwin grep 2.5.1) can handle -P. I do not know if this at all is important - as I said, it is an observation of mine...
Howard Chu wrote: > Alex Vincent wrote: >> Benjamin Smedberg wrote: >>> Alex Vincent wrote: >>> I believe this is because the msys environment comes with an older >>> version >>> of cvs than 1.11.22. I'm not sure there's much you can do about it.
>> At present, I'm trying to figure out who could get that upgraded in >> the msys side of things...
> Earnie Boyd, the MSYS project lead, has gone on sabbatical, so that may > take some time. It shouldn't be too hard to spin an updated cvs binary > though. You might try asking on the msys-devel mailing list. I have > commit rights there but it would be best to coordinate thru their > mailing list.
I'm going to send that note fairly soon. I keep getting the following message:
cvs [checkout aborted]: received broken pipe signal
This issue appears to have been fixed in cvs 1.11.13.
Benjamin Smedberg wrote: > Starting next week the Mozilla build system is going to require python on > all platforms. This will allow us to gradually convert various build scripts > which are currently written in perl, and start hacking on an autoconf > replacement written in python. Any python 2.3 or higher will be acceptable.
What are the advantages of replacing autoconf?
-David
-- L. David Baron <URL: http://dbaron.org/ > Technical Lead, Layout & CSS, Mozilla Corporation
The modularity and maintainability of autoconf scripts is extremely poor, and the learning curve is very high. I believe this can be made better, and I'd like to standardize on as few languages as possible in our build system: python is the natural fit for many reasons including its standard library and readability.
> The modularity and maintainability of autoconf scripts is extremely poor, > and the learning curve is very high. I believe this can be made better, and > I'd like to standardize on as few languages as possible in our build system: > python is the natural fit for many reasons including its standard library > and readability.
I agree that the learning curve is high, but it also seems like a lot of work to do the replacement.
I'm also a little skeptical about modularity gains -- it seems like the modularity of the build system is pretty closely tied to the modularity of the code, and until we're building apps on top of a distinct core, we're going to have a lot of mess in the build system reflecting the way each app builds the core differently, etc.
-David
-- L. David Baron <URL: http://dbaron.org/ > Technical Lead, Layout & CSS, Mozilla Corporation
L. David Baron wrote: > I'm also a little skeptical about modularity gains -- it seems like the > modularity of the build system is pretty closely tied to the modularity > of the code, and until we're building apps on top of a distinct core, > we're going to have a lot of mess in the build system reflecting the way > each app builds the core differently, etc.
We are moving towards the core -> apps pretty quickly. You can already build Firefox-on-XR and the nascent Mozilla Composer-on-XULRunner. There are plans in the works to do the same for Camino and Sunbird, I believe. The mailnews-carrying apps (Tbird and SeaMonkey) are harder, because the mailnews code uses strings so badly that porting it to frozen linkage will be massively hard. But I am definitely moving in that direction. Except for the configure issues, we already have the ability to plug arbitrary directories into the build system and configure with --with-libxul-sdk=path/to/XR/dist --enable-application=myapp which will read build.mk.
> The modularity and maintainability of autoconf scripts is extremely poor, > and the learning curve is very high. I believe this can be made better, and > I'd like to standardize on as few languages as possible in our build system: > python is the natural fit for many reasons including its standard library > and readability.
It sure seems to me like this is going to force a lot of work on certain projects that just don't have the manpower or inclination to rework their build systems right now.
If a project is building with autoconf, and it "ain't broke", then why fix it?
I guess projects that have full time people to maintain and rewrite their makefiles will be happy about this. Full employment for build engineers. But for projects where makefile work takes man hours directly away from the work on the project's main deliverable, this seems like a nuisance.
