> From: [EMAIL PROTECTED] > Tapio Kelloniemi wrote: > > On Sun, Nov 26, 2006 at 09:25:18AM -0500, Chris Staub wrote: > >> No, it's not - it is completely unnecessary. $LFS/sources is only > >> mentioned once in LFS (well, ok, twice...), and even then it's really > >> just a suggestion - the source directory could be anywhere and called > >> anything you like, and no package instructions in either LFS or BLFS > >> refer to any source dir specifically anyway.
I have a different layout. I use /packages/[package name]/[sources, patches and build scripts] to organise the different packages, /build where I extract the source files and build in (e.g. /build/builddir to build gcc, etc. in) and /log for build log output. This is how I have chosen to layout my package build system, but other people will have other layouts. > > What about this (just one example among others). This command can be found > > from the SVN LFS book in one of the GCC sections: > > patch -Np1 -i ../gcc-4.1.1-specs-1.patch I don't think that it is too hard to understand that the path to the gcc patch should point to where it is located on your system. If you can't grasp that, should you really be building LFS? > > This command is to be executed in the gcc-4.1.1 directory and the command > > works if, and only if, the patch file is in the directory just above > > this gcc-4.1.1 directory. I never have built an LFS system, where I could > > have used this command as it is in the book. IMHO all commands that often > > need modification, should be marked as such, eg. > > patch -Np1 -i [your source directory]/gcc-4.1.1-specs-1.patch I think that would complicate matters. All that is required is a line when discussing the $LFS/source directory is to say something like "This book assumes that the tarballs are extracted in the $LFS/source directory." That way, the LFS book is consistent. If you really want, you can add something to the effect of "You can choose to place the source files in a directory of your choosing, but you need to adjust the paths accordingly." However, I think that this is too much. I would put it under the category of "things you need to know and understand before reading the LFS book". > > The LFS layout, where all patches are in ../ is not very practical, since > > in directory listing source directories get buried under the names of > > package > > and patch files. It also makes it impossible to delete the gcc tree like > > this: > > # rm -rf gcc-* So don't put them there. There is nothing preventing you from using a different layout if you don't like the way that it is organised. I am grouping the sources into subdirectories named after the package, as I am keeping the LFS, BLFS and other package sources so I don't need to download them each time. But that is just me :). > Then unpack your source tarballs wherever you like. I still see no > reason to change what's in the book, as I do have all the source and > patches in one dir and have no problems doing it that way. Besides, why > would you need to use "rm -rf gcc-*" to remove the GCC source and build > dirs? It's not that difficult to add the extra "4.0.3" or "build" to the > dir name (or use bash's tab completion to make it really easy). Don't > forget you could also use "tar tf" to list the files in a tarball, or > "tar xvf" for a verbose listing that tells you exactly what's being > unpacked and what directory it's all going into. I use a perl script that does the same thing as: cd /build tar -xf /packages/$PACKAGE/$PACKAGE-$VERSION.tar.* cd `ls` /packages/$PACKAGE/$PACKAGE # run the build script cd /build rm -r * This works very well for me. It is actually a bit more complicated than that, but that is the general idea. When applying a patch, I refer to it explicitly as /packages/$PACKAGE/[...].patch. > Adding a $SOURCEDIR variable where none is needed is just adding another > level of user hand-holding to the book (and there's already enough as it > is). I do not see any point to changing the instructions. I agree. The instructions are clear as they are. - Reece LFS User: 17921 _________________________________________________________________ Be one of the first to try Windows Live Mail. http://ideas.live.com/programpage.aspx?versionId=5d21c51a-b161-4314-9b0e-4911fb2b2e6d-- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
