Dan Nicholson wrote these words on 12/06/05 08:22 CST: > Randy, you said "I'll make the changes." Specifically, which changes? > Object dir? mozconfig? client.mk?
Please, Dan, relax. Gosh, it used to be months sometimes between revision updates to packages in BLFS. Now the expectations are days. :-) It will be some time. I needed to rebuild LFS-SVN for the update to GCC and Glibc (done). So, I'm in the process of installing and testing the packages now. Don't expect me to commit to anything at this point. (This is what I'm getting from your paragraph above). Are you in some big hurry to get this done? If so, sorry, I will work at my own pace. I sure do appreciate your suggestions and help so far, so please continue. And know that I'm listening and will test everything. There are 3 packages to test (I'm looking to standardize the build instructions if at all possible) and there are going to be some subtle differences between them. These are the things I'll be testing. It will take time. For now, here are some thoughts I have so far. 1) Object dir? I can go either way on this. It doesn't benefit the BLFS way of building one bit as we throw away the source dir as soon as the package is installed. Additionally, the reasons you've given for an object dir, don't really come into play for BLFS. (paraphrasing your remarks to the best of my memory/ability) a) "In case you make a mistake and need to untar the big tarball, you just delete the dir and go on". This will never happen. BLFS is already on record in other spots in the book to untar the tarball and start over. Why should Moz be any different? To save the 4 seconds that it takes to untar the tarball again? (even though building the package takes 20-30 minutes). Not hardly a good reason to use different methodology. b) "In case you want to build multiple packages from the same source dir". Again, will never happen. BLFS will never recommend to keep a source dir around in the eventuality that you may use it again to build a *different* package. c) "In case you want to use the same tree for nightly pulls from CVS". This is way beyond BLFS territory. Again, never will happen that this is recommended (or even mentioned) by BLFS. So all that said, I see no benefit whatsoever in using an object dir. However, I'll test using both and see what happens. Bottom line is, I don't know yet. 2) Mozconfig and client.mk to me are mutually together. If you use one, you should use the other. As is mentioned in the Mozilla build instructions (yes, it does say this), you can use mozconfig/client.mk or configure to create the end Makefile used by the make command. I see no reason not to go that route (mozconfig/client.mk) if that is what the community wants. As Tush mentioned, that is how it was but he changed it many years ago so that the instructions were similar to other BLFS instructions. If this is not desired any longer, we should change as that is what is suggested by the Moz developers. (yes, I realize that you'll be able to find at least *one* spot in the Moz build instructions that says they recommend to use an object dir as well. However, do note the reasons they say that *and* there are references to not using the object dir also) 3) Creating a "distribution" tarball and then installing from this probably won't happen unless there is some compelling technical reason that this is better than using 'make install'. And, to me, having a tarball around so that you can install on another machine or in a different directory on the same machine is not a compelling technical reason as this is somewhat contrary to BLFS philosophy of build-it-yourself-and-install-in-a-global-area. > Also, if anyone has good command explanations for any of the obscure > switches like --enable-cpp-rtti, I'll do my best to provide explanations for any obscure switches that still may be used. I don't know if there will be any yet, so it may be a moot point. I'm looking forward to this testing and I will be providing feedback from the testing to this list as I find things out. One thing I will promise, however, is that I'm not going to just dictatorially make changes, present them to the community as updated instructions and ask for commentary. Instead, my plans are that as I discover something I feel should be added/removed, I will ask the group for advice/commentary before I commit changes. My goal is that the community's input is the driving factor in the decisions. (of course, to a degree, as the community decision must adhere to current BLFS policy). Hopefully, this has been of some help and makes sense to y'all. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 08:47:00 up 72 days, 18:11, 3 users, load average: 0.09, 0.04, 0.14 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
