Linux From Scratch This Forum is for the discussion of LFS.
LFS is a project that provides you with the steps necessary to build your own custom Linux system. |
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
|
|
06-10-2003, 02:30 PM
|
#16
|
Member
Registered: Aug 2002
Distribution: SME Server, CentOS
Posts: 219
Original Poster
Rep:
|
Thanks, mdh.
Dark_Helmet, do I understand correctly that except for the commands cut and paste from the book, you typed that whole script by hand? Every last letter? I didn't see much that reminded me of the commands in the book. There was an especially large assortments of variables that must have been a load to type up. It would be extremely useful to know what parts were processed with regular expressions or grep or anything like that.
|
|
|
06-10-2003, 06:03 PM
|
#17
|
Senior Member
Registered: Jan 2003
Posts: 2,786
|
Everything in the script except for the commands from the book was typed by hand, yes. If you want to get technical, no: I wrote the Bash portion by hand (its variables and its entry in the case), pasted a copy of those pieces for each package and then did a repeated search-and-replace to adjust the variable names and their references.
You can find the commands from the book assigned to the series of PRE, CFG, MAKE, INSTALL, and POST variables for each package. If the book did not have a command for a particular step, I just assigned an "empty command" to that variable.
I don't know if I plan to make the script parse the LFS book. That's probably fairly tough to do unless the writers adhere stringently to strict authoring guidelines. I haven't looked at any version of the book's source yet to determine if that is the case. Since nALFS exists, it would seem likely they follow some guidelines, but that still doesn't guarantee strict adherence. Those lovable idiosynchracies tend to turn parsing a file into a patchwork of exceptions... not rules. I'll look into it eventually, but for now, I plan to work on the installation portion until I think it's solid.
|
|
|
06-10-2003, 07:14 PM
|
#18
|
Member
Registered: Aug 2002
Distribution: SME Server, CentOS
Posts: 219
Original Poster
Rep:
|
If you say so ... Thanks.
|
|
|
06-10-2003, 10:10 PM
|
#19
|
Senior Member
Registered: Jan 2003
Posts: 2,786
|
If I were to sit down and poke at it right now, I'd probably look at the XML version of the book first. Then see if they actually separate the commands specifically by tagging them. something like:
<command [attribute ...]>command text</command>
If they did that all the way through the book, then it's simple to grep for the command tag.
Similarly, if they mark a package with an obvious tag like
<package [attribute ...]>package_name</package>
Again, that's simple IF they follow the same tagging scheme throughout the book.
The tricky part comes in when decisions have to be made. I've been reading/using the LFS books off-an-on since about 3.0, and I remember reading statements like this: "If you have an AMD Athlon processor and your distribution is using Glibc <some version> then you need to do this... Do not apply this fix if you do not have this configuration because it is likely to cause a segmentation fault in..." How is the script going to know it's an optional command? How can the script figure out what the conditions are? Even if it can, how would it decide what tests to run to see if it meets the criteria? That's the difficulty I'm worried about.
|
|
|
06-10-2003, 10:31 PM
|
#20
|
Member
Registered: Aug 2002
Distribution: SME Server, CentOS
Posts: 219
Original Poster
Rep:
|
Yes, there appears to be the need to be interactive at some point for a comprehensive script. After a certain point I have to agree with those above who say that we are departing from the spirit of LFS which says anyone who follows the instructions can cobble their own installation of Linux together from just tarred/zipped packages. I really like that.
Since ncurses is part of the installation, maybe there is some way of applying this technology to this purpose. I am thinking about writing a piece like my Software for the Homebuilt Computer site at the link in my signature that would describe the process of making scripts to the complete beginner. I suspect that LFS is maybe a little intimidating for the absolute beginner. And yet that's what I always thought Linux was about when I first got involved with Linux. I was really suprised (relieved ) when I found automatic installations available.
Imagine LFS including such a process by which users were encouraged and taught to write their own scripts. This would closely parallel the fact that they are compiling their own software. Imagine also that they actually took a peek at some of the source code to better understand what they were doing with all the options being set. You yourself say you have some C experience.
When I first considered writing a script, I thought maybe there was some way of applying the "make" and "configure" operation to compile the whole thing as if it were a package of programs. I notice that many of the packages do not appear to be just one compile or make job at once. Some appear to be nested. I guess that there is a compile for each program that is installed in a package or something, I'm not sure.
|
|
|
06-11-2003, 12:24 PM
|
#21
|
Senior Member
Registered: Jan 2003
Posts: 2,786
|
Interesting how things will get you thinking... When you mentioned make, my mind did a 180 and I remembered you can use make to automate things other than compiles. A Makefile is far more cryptic that a shell script, but it should be reasonably easy to create a Makefile that would run a user-defined script for each package. The main benefit of this method would be that you break the installation routine into smaller, more manageable chunks that a beginner could work with. Writing a script to statically install bash is something completely different than a script to install LFS as a whole. Then again, I don't see much room for creativity writing basically the same script repeatedly for each package (aside from maybe displaying status messages, re-directing output, etc.).
|
|
|
06-11-2003, 02:06 PM
|
#22
|
Member
Registered: Aug 2002
Distribution: SME Server, CentOS
Posts: 219
Original Poster
Rep:
|
Well, food for thought anyway.
|
|
|
06-11-2003, 05:03 PM
|
#23
|
Senior Member
Registered: Jan 2003
Posts: 2,786
|
Forgot to mention:
Quote:
I notice that many of the packages do not appear to be just one compile or make job at once. Some appear to be nested. I guess that there is a compile for each program that is installed in a package or something
|
I'm not sure I follow that first sentence correctly. Which packages don't? Well, almost all of them do "make" then "make install". If I understand make correctly, you could simply issue "make install" by itself and it would imply the original make (it can't install the binary until it's been compiled, which forces it to do the compile).
I'm not sure how familiar you are with make. If you know it pretty well, then you'd probably find this boring to say the least...
Yeah, every individual binary contained in a package gets a compile on its own. When you run configure, it generates all the necessary Makefiles for those programs. Usually there is a subdirectory for each binary to compile, and that subdirectory will have its own Makefile to direct how that binary will be compiled. Issuing make at the root of the source tree essentially starts a batch compilation of all those binaries in all the subdirectories with a single command.
|
|
|
06-12-2003, 12:07 AM
|
#24
|
Member
Registered: Aug 2002
Distribution: SME Server, CentOS
Posts: 219
Original Poster
Rep:
|
Quote:
... Usually there is a subdirectory for each binary to compile, and that subdirectory will have its own Makefile to direct how that binary will be compiled. Issuing make at the root of the source tree essentially starts a batch compilation of all those binaries in all the subdirectories with a single command.
|
Right. And the collection of packages could be considered to be in subdirectories of a directory for which there could be a make file that runs the rest? This is what I wonder about.
|
|
|
06-12-2003, 01:56 AM
|
#25
|
Senior Member
Registered: Jan 2003
Posts: 2,786
|
Ok, now I understand what you were getting at. Yeah, you could set up a super-directory to coordinate compiling the individual packages, which in turn, coordinate compiling the individual binaries.
I think that would be considered the mother-of-all-make-commands...
|
|
|
06-12-2003, 02:29 AM
|
#26
|
Member
Registered: Nov 2002
Location: Melbourne, Australia
Distribution: (C)LFS (x86_64, ix86, sparcv9, ppc)
Posts: 122
Rep:
|
I think you may wanna have a look at how the Free/OpenBSD people get the job done if you wanna play with make...
"make world" is a wonderful thing ;-)
Seems the closest thing I can think of to what you guys are trying to achieve...
|
|
|
All times are GMT -5. The time now is 10:30 PM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|