On 12/5/05, Jeremy Huntwork <[EMAIL PROTECTED]> wrote: > Randy McMurchy wrote: > > > Because no matter how you execute the configuration stage, you end > > up with the *same exact* thing. I would have thought you knew that. > > This is not intended to start an argument, but I really am just curious. > If in fact both methods do produce the same results, what is mozilla's > reason behind their suggested method and why was it ever considered a > good thing to break from it in the first place?
I'm kind of speculating, but these are the major reasons, I think: 1. They have a lot of custom autoconf type scripts to hash out the myriad options and arches that it's built for. This is kind of what I pointed out: instead of passing a 30 line configure statement, you can use a simple text file. This method allows to also use the default options a lot easier. It's pretty straightforward to get stock firefox with . $topsrcdir/browser/config/mozconfig. 2. There's a lot of custom CVS pulling stuff in there to handle the tons of branches and projects they have. client.mk makes it sane to maintain a single source tree and try to build multiple projects from it. Have you ever taken a look at their CVS tree? It's insane: http://lxr.mozilla.org/ And, yes, there are people who successfully build multiple projects (suite, browser, etc.) from a single source tree. I've wondered this myself a few times, especially for #1 and for why they don't go fully autotooled. In the end, though, they decided to make a customization of the CMMI system to support their huge source tree, and now it's pretty mature. It certainly doesn't take a wizard to figure out how to use it (especially with the docs), and it's backwards compatible to standard CMMI, anyway. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
