Hello,

I'm normaly just a LFS+BLFS user and don't say much on those lists. I read most of lfs-dev though.
I have a question of which I'm not sure if this is the right place to ask, but it felt a bit too much to post to lfs-dev, clfs-dev, hlfs-dev and such...

My question is about the sub-projects.
It's nice to fork now and then to try some different path, or to do stuff for a specific task, but sometimes it creates a lot of double-work.

about CLFS,
CLFS can be used to build a "normal" (not cross-compiled) system as well... most instructions look the same as LFS and as far as I can see there are not many big differences.
It takes a little longer to compile, but the build-method used is very clean I think.
What's the point in keeping it separate from normal LFS?
As far as I can see CLFS is almost the same as LFS. LFS takes a little shortcut (adjusting the toolchain) which CLFS doesn't but wouldn't it be more efficient to use the CLFS method and just say "this part can be skipped/shortcutted if you build for the same architecture" ?
I know there are some parts that differ (bootscripts, udev-stuff), where both teams have different opinions, but isn't it wiser to sort things out at branch-level instead of project level? just like the alphabetical stuff, and the udev_update stuff.
Are there any plans to merge CLFS and LFS in the near- or distant future?

about HLFS I have almost the same question.
I know HLFS is a bit different but in a way I would like it like this:

just _ONE_ LFS project, maybe a few branches to test new stuff.
in this one LFS book there will be some instructions or patches that are architecture/CLFS/HLFS specific...
these should just get a different background-color or surrounding.
This way there isn't any double-work and everything is in one place. Also for learning this is great. People just building normal LFS will see some instructions that are HLFS-specific. They might get interested, and understand why this specific patch/instruction goes at that point in the book.
Next time they build a system they want to try the HLFS parts.


Sorry for my bad english, and for my absolute lack of technical knowledge about these issues.
I'm very curious by nature and I want to understand how and why things work the way they do.
By checking out 3 not-so-different projects I fail to keep a nice overview of the whole xLFS and what they have in common.

thanks for any answers and keep up the good work

Mathijs Kwik
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to