Closed
Bug 57282
Opened 24 years ago
Closed 22 years ago
Building components selectively
Categories
(SeaMonkey :: Build Config, defect, P2)
SeaMonkey
Build Config
Tracking
(Not tracked)
VERIFIED
DUPLICATE
of bug 173066
mozilla1.2final
People
(Reporter: hsivonen, Assigned: cls)
References
Details
(Keywords: embed, topembed-)
Attachments
(3 files)
6.19 KB,
patch
|
Details | Diff | Splinter Review | |
10.50 KB,
patch
|
Details | Diff | Splinter Review | |
1.41 KB,
patch
|
Details | Diff | Splinter Review |
Currently the build system attempts pull the entire SeaMonkeyAll from CVS even if you only want to build some components. As a result, building selected components of Mozilla is not feasible in a disk-space-challanged environment. It would help if the build system pulled only the sources required to build selected components.
This can already be done to a point on the unix side. cvs -z3 co mozilla/client.mk cd mozilla make -f client.mk pull_all BUILD_MODULES=xpcom,js ./configure --enable-modules=xpcom,js The list (build/unix/modules.mk) is far from complete, but it's a start. I'm not sure what the plans are for duplicating this functionality on windows or mac.
Status: NEW → ASSIGNED
Comment 2•24 years ago
|
||
To do selective checkouts and builds on Mac, you'll have to create new files for the build. You should clone and modify the following files MozillaBuildFlags.txt MozillaCheckoutList.txt BuildMozillaDebug.pl BuildMozilla.pl PullMozilla.pl and possibly MozillaBuildList.pm if you can't leverage the existing project groupings.
At first glance, there appears to be no way to avoid building certain modules standalone without losing functionality (via ifdefs) or building much more than is needed for the standalone case (upto 10 additional modules depending upon dependencies). Case-in-point, xpcom. To build xpcom standalone means that you lose support for intl string handling in the nsCRT & nsLocalFile classes among other things. But to build the libraries required for intl string handling means dealing with another slew of deps outside of xpcom (like prefs, js, necko: and then deal with all of necko's deps). Now, in xpcom's case, the extra module deps are actually components so (in theory) they should be runtime optional. So, assuming that the goal of a standalone module is to encompass the same functionality as the non-standalone version, the ifdef solution needs to be shown the door. I'm not extremely familiar with other COM implementations but I was under the impression that each module that depends upon a component needs to Do The Right Thing(tm) if the component is not available. So assuming this is true, then all we really need to worry about is the external headers that declare the component interfaces used by a module. 1) The first option is to modify the existing standalone build arch to contain a list of dirs that are only traversed to export headers which should get rid of the cascading dependency problems. 2) The second option is to create a toplevel interfaces/ directory that would contain the actual public headers for the modules. For starters, I'm thinking about just moving the .idls to interfaces/. This way, we can clearly outline what the public interfaces of a particular module are and people who want to build xpcom or some other intl depend module standalone do not have to pull the entire intl source. Option 1 is fairly straightforward. The changes would not affect the normal build process. The only possibly side-effect would be if a module did something non-standard during the export phase (which most do not). And the downside is the additional source directory requirements. Option 2 is quite a bit more complicated and it does require changing the normal build process. It does allow us to clearly outline what the public interfaces of a particular module are and people who want to build xpcom or some other intl depend module standalone do not have to pull the entire intl source to use it. Any thoughts?
Target Milestone: mozilla0.6 → mozilla0.9
To test, you need to do this: cvs -z3 co mozilla/client.mk cd mozilla make -f client.mk pull_all BUILD_MODULES= env POSIXLY_CORRECT=1 patch -p0 < ~/standalone.patch make -f client.mk pull_all BUILD_MODULES=xpcom ./configure --enable-modules=xpcom make Ok, so what am I actually doing here? In build/unix/modules.mk, I'm creating a list of dep dirs in the same way that I create BUILD_MODULE_DIRS. Then I added a new rule set to config/rules.mk that causes recursive makes to be triggered if EXPORT_DIRS is set and it is only set in the toplevel Makefile. By adding intl & modules/libjar to the dep list, I am able to build xpcom and run nsTestSample without actually building the intl nor libjar components. Side notes: Right now, it's still kinda lame that we still require the module deps to be kept in 2 places (modules.mk & allmakefiles.sh). Eventually, --enable-module should be renamed to something like --enable-standalone.
Comment 6•24 years ago
|
||
Looks good, r=jag
Attachment 21318 [details] [diff] contains changes to make building standalone more efficient.
Instead of pulling a toplevel directory like xpcom or intl (which are the entry
points for building those modules) for standalone builds, we will actually list
the directories we need to pull. Since I was unable to find a way to duplicate
the exclude feature of cvs modules (!mozilla/dir), I modified client.mk so that
it will pull a specified list of directories using the no-recurse option (-l) so
that we recursively pull directories that we do not need. For example, when
building js standalone, we do not need js/src/perlconnect, js/src/liveconnect,
etc, so we just add js js/src & js/src/fdlibm to the no-recurse pull list. The
downside of this is that build maintainers have to be more vigilant about
tracking intermodule dependencies or else the standalone builds will be prone to
breakage.
Comment 10•24 years ago
|
||
Those checkins broke the transformiix standalone build :-(. We need a _CVS_ in modules.mk, too. Adding this brings up two other bugs. They are fixed in my tree now. BUILD_MODULE_CVS_NS and BUILD_MODULE_DEP_DIRS can be empty, the checks are either missing or wrong (as they are defined). Patch follows in a second. Axel
Comment 11•24 years ago
|
||
Assignee | ||
Comment 12•24 years ago
|
||
Sorry about breaking transformiix. r=cls
Comment 13•24 years ago
|
||
fix for simple modules checked in Axel
Comment 14•23 years ago
|
||
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Comment 15•23 years ago
|
||
don't move bugs that are in the 1.0 dependency tree. sorry.
Target Milestone: mozilla1.0.1 → mozilla1.0
Updated•22 years ago
|
Updated•22 years ago
|
Target Milestone: mozilla1.0 → Future
Comment 16•22 years ago
|
||
This should be fixed by the checkin for bug 173066. modules.mk is generated using the module dependencies listed in Makefiles by REQUIRES. See http://lxr.mozilla.org/mozilla/source/tools/module-deps/bootstrap.pl . The full list of modules (currently 147) can be found at the generated modules.mk. See http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/build/unix/modules.mk#45 *** This bug has been marked as a duplicate of 173066 ***
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Target Milestone: Future → mozilla1.2final
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•