Closed Bug 105581 Opened 23 years ago Closed 23 years ago

Built Mozilla -- now what???

Categories

(SeaMonkey :: Build Config, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 56601

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". 



*** This bug has been marked as a duplicate of 56601 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
verified.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.