Closed Bug 56601 Opened 24 years ago Closed 22 years ago

Mozilla needs a real install target

Categories

(SeaMonkey :: Build Config, defect, P3)

Product:
SeaMonkey
Component:
Build Config
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: cls, Assigned: cls)

References

Details

Attachments

(1 file, 10 obsolete files)

install patch + jars patch applied to 1.0 branch
79.58 KB, patch
endico
: approval+
Details | Diff | Splinter Review 
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.
Status: NEW → ASSIGNED
Blocks: 58372
Target Milestone: --- → mozilla0.9
Target Milestone: mozilla0.9 → mozilla1.0
*** 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.

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.
Attached patch Rename install phase to libs (obsolete) — — Splinter Review 
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
Keywords: mozilla1.0+
Target Milestone: mozilla0.9.9 → mozilla1.0
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).
Attachment #58592 - Attachment is obsolete: true
Attachment #58644 - Attachment is obsolete: true
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.


> 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. ***
Blocks: 134204
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
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.
Depends on: 138442
Attached patch Updated patch against trunk (obsolete) — — Splinter Review 
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.
this should let "mozilla-0.9.9+" style directories get created and installed-to
correctly
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+
Attached patch make install v4 (obsolete) — — Splinter Review 
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
Attachment #79972 - Attachment is obsolete: true
Attachment #80266 - Attachment is obsolete: true
Attachment #80609 - Attachment is obsolete: true
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.
Keywords: adt1.0.0
Whiteboard: [fixed on trunk]
Whiteboard: [fixed on trunk] → [fixed on trunk][drivers queue]
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
Closed: 22 years ago
Resolution: --- → FIXED
Whiteboard: [fixed on trunk][drivers queue]
Keywords: fixed1.0.0
Keywords: adt1.0.1
Removing adt1.0.0, and adding adt1.0.1, as we have changed milestones.
Keywords: adt1.0.0
Keywords: adt1.0.1
verified
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: