It's kinda hard to use an app full-time while hacking on the shared libraries that it uses. The installer is overkill for a developers build and tarring up everything under dist is really unnecessary. I loathe the thought of adding another pass to the build so I'm wondering if we could get away with just adding a "real_install" target to the toplevel Makefile. The problem then becomes, what do you install? I suppose we could just parse the xpinstall packages to start with and work our way up to something more complicated.
Have a look at the rpm spec file that I use. It's dead simple.
*** Bug 99906 has been marked as a duplicate of this bug. ***
*** Bug 105581 has been marked as a duplicate of this bug. ***
In case people don't look at the crossed-out bugs that were marked as duplicates of this bug, both suggested that Mozilla honor the standard syntax: ./configure --prefix=/some/path Ideally, all build options should be able to passed via configure. There should no need for these custom environment variables that specify, for example, the build number. Nearly every other open-source project of any significance adheres to this standard, and it greatly simplifies the installation and distribution process for the end-user (I personally don't want things to evolve to the point where I'm visiting the developers' web page for every tarball I download, because everybody's got their own custom installation procedure).
No need to duplicate rants. We're well aware of the situation here. It's just not a high priority considering other issues that need resolving.
Didn't mean to rant. The browser is excellent, the only one I use other than Lynx. Just didn't want the --prefix comments to get overlooked--it's a cleaner solution than editing Makefiles or setting environment variables. m.
yeah that's real hell installing mozilla! compiles longer than XFree86 4.1.0 only to get a dir full of symlinks, and the mozilla tree directory gets 1.5G !!! is this THAT hard to make configure --prefix=/some/dir, as well-mentioned by karmak, to really install mozilla in /some/dir i think that answer : "It's just not a high priority considering other issues that need resolving." is a mere blabber. no offense, of course, but I think that it's very high priority issue as anyone wanting to install from source need this, and i'm sure it may be resolved easily. why not to do it???
Easy there ;-) While a standards-compliant installation procedure is certainly important, perhaps more so than the developers realize, yelling at them isn't very polite. :) Admittedly, this is exactly how I felt the first time I wiped out 45 minutes of compilation because --prefix didn't put files where I told it to, and I probably came off as ranting myself. I hope the developers realize it's just frustration talking at times like this. The effort that has gone into this project is not overlooked, and everyone deserves much more praise than criticism. I'd say the best thing we could do is encourage people to vote for this bug. I suspect the more votes a bug gets, the more attention developers will pay to it. If you can find anyone else who feels this way, try to get them to take a few minutes to come cast their vote. And cast the vote yourself--I still see only one vote, which I believe is my own.
Created attachment 58516 [details] [diff] [review] Renamed install phase to build phase make install has pre-existing connotations in the unix build world and populating a subdir local to the package isn't one of them. This patch renames the 'make install' phase to 'make build' for Mozilla. NSPR & LDAP are untouched.
Created attachment 58592 [details] [diff] [review] Rename install phase to libs nmake is lame and doesn't allow you to have makefile targets that conflict with existing files or directories. Since we have several dirs named build, I had to switch back to using libs. And before someone asks, I'm changing win32's targets as well as we usually try to make sure that the basic design of both build systems is fairly similar.
Attachment #58516 - Attachment is obsolete: true
Well, somebody has to say it... I'm not very happy with renaming 'install' to 'libs'. That turns many years of reference in this codebase on its head. Next we'll be calling red blue and green red? I understand the Linux heads have some prior claim on 'install' and that 'build' turns out to be a bad name. But recycling 'libs' to mean something completely different than it ever meant before is just confusing. Are there no other acceptable 'build'-like words that are not being used as directory names that could be used? 'compile'? 'translate'? 'dlls'? 'generate'? Maybe I'm just on the losing side and we'll all just have to readjust our thinking in the name of greater harmony. Whatever. Also, what exactly is 'install' going to mean in this new world as applied to Win32? Something more than it has meant and less than packaging? Not more manifests I hope. And one more thing to wind up my whiney rant... cls: please announce stuff like this to the builds newsgroup (If you did I missed it). You also could have left in a temporary 'install' target that spits out some text explaining the change. Warren did this when he whacked libs in the win32 build and it helped people adjust. It's not nice to make people go figure out on there own why things are suddenly not working as before. To be fair, I've seen you announce other build changes. But, I got 'burned' by this and the build_all_dep change too.
'make install' has to change. It's not just "Linux heads" that use it -- it's pretty much the entire open-source community. Go to a developer hosting site like Sourceforge and you'll notice that virtually all of the projects define 'make install' in the same way. To not just ignore the standard, but to go as far as _redefining_ it, is bordering on hostility. configure; make; make install A 3-step process, with a 'make check' optionally thrown in for good measure. This is where the open-source community is headed. It makes no sense to support dozens of legacy and/or "proprietary" build methods for the sake of nostalgia. It may take extra time and effort to standardize, but compared to the net loss of efficiency that comes with fragmentation, it's a far smaller price to pay.
Target Milestone: mozilla1.0 → mozilla0.9.9
Target Milestone: mozilla0.9.9 → mozilla1.0
Created attachment 73662 [details] [diff] [review] Initial all-inclusive install patch This patch includes the 2 patches from bug 129456. With this patch, the directory structure of a mozilla install will look like: /prefix -> /bin/mozilla /include/mozilla-ver /lib/mozilla-ver (mozappdir) /components /res /defaults /chrome /mre/mre-ver (mredir) /components /bin/mozilla is the shell script that we use to start the build. This script will know about the location of the mozilla application directory (/lib/mozilla-ver) and the mozilla runtime environment directory (/mre/mre-ver). The mredir will eventually contain whatever common files are defined to be the mozilla runtime environment. For the moment, I've just tested putting runtime libraries there. IIRC, the component manager would need to be tweaked to support multiple search paths for components so it may be a bit before we have full MRE support. The mozappdir will contain all of the Mozilla-the-application specific files, which should be everything else...chrome, prefs, res, etc. Right now, all of the application libraries are stored in mozappdir. If we ever get to the point of versioning our libraries, we might want to start placing those libraries in /prefix/lib/ so that they can be reused by other applications. Note: mozilla-config still needs to be updated to handle the new directory structure. Atm, I'm not sure how to proceed a SDK that would correspond to the MRE. It needs to be strongly coupled with the MRE so I'm tempted to say just put it under the mredir but I'm sure that'll violate some FHSes. And /include/mozilla-ver should eventually go away completely, to be replaced by the frozen embedding APIs that will be the official (defacto?) standard for using the MRE (gecko & friends).
There are already some libraries being used by external libraries. These are, at least: /usr/lib/libgkgfx.so /usr/lib/libgtkembedmoz.so /usr/lib/libgtksuperwin.so /usr/lib/libgtkxtbin.so /usr/lib/libjsj.so /usr/lib/libmozjs.so /usr/lib/libxpcom.so /usr/lib/libxpistub.so /usr/lib/libnspr4.so /usr/lib/libplc4.so /usr/lib/libplds4.so /usr/lib/libnss3.so /usr/lib/libnssckbi.so /usr/lib/libsmime3.so /usr/lib/libsoftokn3.so /usr/lib/libssl3.so They should end up in /usr/lib, in the normal library path.
The placement of those libraries in /usr/lib without proper versioning information has always been a bone of contention. NSPR, NSS & JS are the only libraries that have actually been frozen at some point so they should be the only ones that are installed in a system directory. However, because the lack of proper versioning, you cannot tell which release of the library that you have installed. Right now, you cannot install multiple versions of Mozilla using the rpms. Or for a more realistic end-user case, on RH7.2, you cannot upgrade to Mozilla 0.9.9 without uninstalling RH7.2's galeon (0.9.4 based) because they both use/provide /usr/lib/libxpcom.so but those are clearly distinct and incompatible versions of the library. Hence the need for something like the MRE which will separate the non-frozen/non-versioned libs from the rest of the system. The idea, which comes from the embedding SDK doc ( http://www.mozilla.org/projects/embedding/EmbeddingSDKSpec.html ), is to version the set of runtime libraries as a whole rather than each individual library. Yes, 3rd party users of those libraries will have to recompile their apps (at least once) if we move to this scheme but right now, they have to do that anyway each time that you upgrade Mozilla.
That's all well and good, but this means that all apps that use those libraries will have to have hard coded knowledge about where to find those libraries, either by every program having to be front ended by a script or some other such nonsense. There are apps out there using this stuff, and this is a pretty major change. As for the fact that galeon needs to be unsintalled, that's because they reach down deep into the internals of the libraries and are always wedded to a specific version. I don't know. It seems like one is no worse than the other. Marco? Frank? What do you think?
Since this is on the whiteboard for the 1.0 release, maybe it should depend on bug# 53727 (libraries need soversions) ? This would remove all the contentions of putting the libs in $prefix/lib and those who want a second mozilla installation can put it in /opt or /usr/local. The whole point of using prepackaged software is so that you always have a unique version to avoid confusion.
Blizzard, you are correct. The apps will need to hardcode paths to those libraries (-rpath), use shell scripts or an env variable (MRE_HOME) to locate those common libraries. On the surface, it sucks. But really, what good does being able to search the library paths for libxpcom.so do you when you can only use a specific unlabelled version safely? This is a major change and it's not backwards compatible with the existing defacto standard for system installs of Mozilla. Since the defacto standard is based on a convention that Mozilla doesn't currently follow, namely frozen & versioned libraries, a defacto standard install is essentially broken for us. Obviously, something has to change. >maybe it should depend on bug# 53727 (libraries need soversions) ? Unfortunately, just having soversions isn't enough. > The whole point of using prepackaged software is so that you always have a > unique version to avoid confusion. I agree completely. However, as you can see from bug 53727, there's some disagreement here as how to uniquely identify versions of software. IMO, any libraries installed in a system directory (/usr/lib, /usr/local/lib) should be properly versioned. That is the current convention. However, based upon comments from bug 53727 and the various other MRE/SDK bugs, developers do not anticipate that our application libraries, much less the component libraries, will be frozen by the moz1.0 release* and if they are not frozen, then what's the practical value in versioning them? If we just arbitrarily version the application libraries, then we break the convention outlined at http://www.usenix.org/publications/library/proceedings/als2000/full_papers/browndavid/browndavid_html/#pgfId-998540 wrt major & minor numbers** and we _still_ have the issue of component libraries to worry about.*** If we follow the MRE approach, then there's no convention to worry about and we can arbitrarily version the group of libraries as we see fit. * So if nothing's frozen and the application feature set isn't complete, _why_ are we making a major 1.0 release? ** This is assuming that we use the milestone numbers as our arbitrary versioning scheme and doesn't even touch the issue of nighlty builds. *** In case it wasn't clear, we are worried about the component libraries as they make up a large part of the code that 3rd party application will want to reuse.
Looks like current proposal would give galeon some problems (I hope to not be missing something) 1 With libraries api freeze we hope it will be possible to to have galeon compatible with newer mozilla version without source/binary incompatibilities. Putting mozilla libraries in /usr/lib/mozilla-ver will require us to update our shell script for every mozilla version to export the right LD_LIBRARY_PATH, requring a new galeon release. 2 At compile time all users will need to use --with-mozilla-libs --with-mozila- includes to specify the location of mozilla libraries. This would be a regresssion compared to current situation (with mozilla packages like blizzard rpms). I think making the process easy with only one mozilla version installed should have higher priority than make possible to have two mozilla installation coexisting. (still possible using two different prefixes) Linux application install libraries (and binaries) in a conventional location where users (applications or humans) can find them. I think mozilla should follow the same rule at least on linux.
> With libraries api freeze ..... With *what* library api freeze? We have some frozen APIs but outside of the libraries that are used in Netscape server projects (NSPR & NSS), there has been no indication that we will be freezing _any_ libraries anytime soon. We have some people working on things like libxpcomglue (bug 130405) just so that we don't have to be constrained to freezing libxpcom. We all really need to get everyone on the same page here. > Putting mozilla libraries in /usr/lib/mozilla-ver will require us to update our > shell script for every mozilla version to export the right LD_LIBRARY_PATH, > requring a new galeon release. You're assuming that each Mozilla release is binary compatible with the previous one. That has not always been the case and since we're telling people that they shouldn't be linking against libxpcom, one of our most base libraries, I'm guessing that it's not going to be the case for quite some time. As with the current situation, when a new release of the MRE/Mozilla comes out, more than likely, you'll have to recompile galeon against the new libxpcom.so anyway; so whether it grabs the library from /usr/lib/mozilla-ver or /usr/lib seems secondary. Using .../mozilla-ver allows us to support multiple installations of the MRE, not just Mozilla-the-application. Since, currently, nothing is versioned, installing everything in /usr/lib forces everyone to upgrade in lockstep whenever a new version of Mozilla or the MRE is installed. That's bad. See http://www.mozilla.org/projects/embedding/MRE.html for the recently ugpraded propsal on the MRE. > At compile time all users will need to use --with-mozilla-libs --with-mozila- > includes to specify the location of mozilla libraries. Or we could fix up `mozilla-config` to properly handle the new versioning scheme and provide the proper link paths. > I think mozilla should follow the same rule at least on linux. As I stated before, this means getting developers to agree on freezing libraries and properly using the correct versioning scheme. Without developer buy-in, trying to force Mozilla libs to adhere to the versioning convention just not going to work. But as usual, feel free to prove me wrong.
Created attachment 74200 [details] [diff] [review] Same patch minus checked in REGCHROME changes
Attachment #73662 - Attachment is obsolete: true
> See http://www.mozilla.org/projects/embedding/MRE.html for the > recently ugpraded proposal on the MRE Hmmm the proposal doesnt include unix platform specifications. Anyway if the unix part is going to be similar to the windows one, requiring a script to run the application, then your patch make sense. I would strongly dislike it but I guess this is offtopic here. The way files are organized in blizzard rpms is simple and easy. I have never got a complain about compiling/installing galeon with these mozilla packages. My impression is that the MRE and these building changes are just going to make the process of installing and developing an embedding application more complex for linux users because they are not consistent with other linux apps installation process and because they probably require an installer to get the setup done in one step. I hope I'll be proved wrong. >Or we could fix up `mozilla-config` to properly handle the new versioning >scheme >and provide the proper link paths Right. (I thought to it just after committing my comment yesterday) But please get it done :) > As I stated before, this means getting developers to agree on freezing > libraries and properly using the correct versioning scheme. Without > developer buy-in, trying to force Mozilla libs to adhere to the versioning > convention just not going to work. Being not able to get developers to agree on a convention is not a good reason to establish another convention that only mozilla is going to follow. In fact the MRE plan establish another convention: "The version of the libraries is given by the name of the directory containg them" Anyway now I stop complaining, sorry :)
*** Bug 107764 has been marked as a duplicate of this bug. ***
Wouldn't bug 134204 solve the issue of client projects finding the correct version of a mozilla.org library they depend on? Are there folks that find a pkgconfig dependency objectionable?
No longer blocks: 134204
Sure, pkgconfig/mozilla-config/moz.m4/etc could help solve the problem of finding the proper versions of mozilla libraries. However, that's really a secondary issue that we can cover later. The issue that is still of primary importance is determining *where* the files should be put on the system. I think Blizzard & Marco have made it clear that the current plans are suboptimal for projects that are *already using* Mozilla libraries. This isn't some fictious embedding consumer that may be on the Linux embedding radar in Q4 2002 (completely made up, fwiw); we have people using the code right now. Do we (read: people in charge of freezing libraries and handling embedding concerns) have any plans of addressing those concerns? Chak, can you please update the MRE document with the proposed Unix changes so that others can see exactly what's being planned here?
Well, as has been mentioned, those projects that depend on Mozilla tend to have to put out a new release with each new Mozilla milestone *anyway* because binary compatibility has been broken somewhere or other. This is just another binary compatibility issue. Given the track record to date, I don't see what the big deal is about breaking it here.
Created attachment 79972 [details] [diff] [review] Updated patch against trunk This patch requires the ldap changes from bug 138442.
Attachment #74200 - Attachment is obsolete: true
Looks ok to me after looking at the changes and asking several questions. Note that the MRE work is really scaffolding for later. Please remove MRE_DIST = 1 from the xpcom/build/Makefile.in, this should not go into the tree that way. I'm not a makefile wizard, so someone else should review for detail. And I can't give sr= for this. But just tossing in a general thumbs up for the changes.
Created attachment 80520 [details] [diff] [review] make-jars.pl doesn't handle paths with "+" in them; if we're using milestone.txt for milestone value, it can have "+" as a character. this should let "mozilla-0.9.9+" style directories get created and installed-to correctly
Created attachment 80609 [details] [diff] [review] patch 79972 dropped a line in rules.mk to invoke make-jars.pl that shouldn't have been dropped. i know cls is getting a new patch ready, but i thought i'd post this, because it makes building a clean tree possible.
Comment on attachment 80520 [details] [diff] [review] make-jars.pl doesn't handle paths with "+" in them; if we're using milestone.txt for milestone value, it can have "+" as a character. r=cls
Attachment #80520 - Flags: review+
Created attachment 80688 [details] [diff] [review] make install v4 Changes from previous patch: * Replaced missing jar file rule (thanks for the catch, leaf!) * Removed sample MRE_DIST setting from xpcom/build/Makefile.in * Added EXTRA_COMPONENTS variable & ruleset to reduce the number of local Makefile rules used to install js components in $(DIST) & $(prefix) * Use SYSINSTALL in 'install' rules intead of explicitly spelling out $(NSINSTALL) -t * Generate mozilla-config from Makefile instead of configure * Modified mozilla-config to use -L$(mozappdir) for libs instead of standard $(libdir) location * No longer install nspr-config
Comment on attachment 80688 [details] [diff] [review] make install v4 the first time i made install with this patch, mozilla-config was empty. i haven't been able to reproduce that, though, so i'm going to r= the patch. I'll get the make-jars.pl change for "+" in as soon as the tree is open.
Attachment #80688 - Flags: review+
Attachment 80688 [details] [diff] has been checked in on the trunk.
Whiteboard: [fixed on trunk]
Whiteboard: [fixed on trunk] → [fixed on trunk][drivers queue]
Created attachment 84948 [details] [diff] [review] install patch + jars patch applied to 1.0 branch
Comment on attachment 84948 [details] [diff] [review] install patch + jars patch applied to 1.0 branch a=scc,shaver.tor please check in today.
Attachment #84948 - Flags: approval+
Attachment 84948 [details] [diff] has been checked into the mozilla 1.0.0 branch.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Whiteboard: [fixed on trunk][drivers queue]
Removing adt1.0.0, and adding adt1.0.1, as we have changed milestones.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.