Closed
Bug 105581
Opened 23 years ago
Closed 23 years ago
Built Mozilla -- now what???
Categories
(SeaMonkey :: Build Config, defect)
Tracking
(Not tracked)
People
(Reporter: karmak, Assigned: netscape)
Details
After a successful build, I end up with a 'dist' directory full of symbolic links. Apparently passing --prefix=/some/path doesn't do what it's supposed to. So now, how do I go from a 'dist' directory full of symlinks to something that I can actually distribute? The build instructions seem to have left out this final (and crucial!) step. IMO this shouldn't be an issue at all. ./configure --prefix=/some/path should put the files where I tell them--like other normal, well-behaved configure scripts. At the very least an error should be thrown saying that --prefix is not supported. It is somewhat irritating to do a 'make install', assume that the files have been put _outside_ the source directory where I've told them to be put, then do a 'make distclean' only to see 45 minutes of compilation go down the drain when you realize 'make install' never actually took the files out of the source directory... Regardless of whether ./configure gets fixed or not, the pressing issue is how to get the necessary files out of 'dist' and into something I can actually dist. Dist-ing a bunch of symlinks isn't very useful. m.
Is this a bug? I thought the "Building A Mozilla Distribution" found at http://www.mozilla.org/build/distribution.html told how, in combo with the path info etc. found at http://www.mozilla.org/build/unix-details.html
The procedure is overly complex. Yes, I am intelligent enough to figure it out, but I shouldn't have to. Creating mozilla/.mozconfig, setting custom environment variables, running a custom 'packager'; it's a unique process that rejects years of work that have gone into standardizing the "configure; make; make install" process. There are great benefits to being able to set standard build variables (CC, CFLAGS, etc), pass the desired options to configure, then sit back and let the machine do the work. With a single shell script that is customized to your environment, you can automate the entire build process, from a source code tarball to a stand-alone build directory that contains everything you need to run the program. From that point, distribution is simply a matter of zipping up the build directory and passing it on. Unfortunately though, there are still packages like this one, where the procedure differs so significantly that you spend hours studying documentation and performing trial-and-error to achieve the relatively simple task of compiling the program and putting the files where you want them to go. Yes, the documentation is there, but my complaint is that it shouldn't have to be. As for whether or not there is actually a bug here, there is a convention that says when one passes --prefix=/some/path to configure, that's where files are going to be installed. To do otherwise (and especially to accept the prefix flag and then ignore it without warning) is IMO a rather significant flaw.
A follow-up to the follow-up: Imagine if every tarball you ever downloaded required you to go to the developers' web page and read custom documentation on how to compile it and put it in the desired directory. Download bash; go to the bash page and see how to install it. Download sed; go to the sed page and see how to install it. It would drive us all nuts. Breaking from traditions like this can only hurt the open-source community. The more difficult we make it to accomplish common tasks, tasks for which standards greatly streamline the development process, the more put-off people are going to be. I personally don't even want to bother trying to get Mozilla to build the way I want it to--it's just too much of a time investment. I can build a dozen programs (ones with standard ./configure scripts) in the time it takes me to read a single page of the Mozilla documentation. The standard configure process has worked fine for years and continues to be the the most powerful, flexible method available. To expect people to spend the time learning some entirely new procedure just for the sake of building _one_ package is unrealistic. I suspect I'm not the only one who has looked at the morass of custom distribution instructions and just said "forget about it, I'm not _that_ interested in distributing Mozilla after all".
Assignee | ||
Comment 4•23 years ago
|
||
*** This bug has been marked as a duplicate of 56601 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•