Re: [RFC] remove obsolete clfs code in jhalfs

On Wed, 23 Feb 2022 at 22:59, Pierre Labastie
<[email protected]> wrote:
>
> Hi, It looks like clfs has been dead for 5 years now, and clfs-embedded for
> slightly less.
>
> I'd like to remove all the code related to this (and also some remnants of hlfs
> code). That would reduce the code and make it easier to maintain and update (it
> would be useful to add the possibility to build [1] for example), specially
> because the code for LFS has evolved to be rather different from its original
> design, while that of clfs has remained the same.
>
> But before that, I'd like to get comments from users to see if they would miss
> the clfs support.
>
> Sending to lfs-dev too, not lfs-support. I am not subscribed to clfs-dev, but
> maybe this could be transferred to them
>
> [1] https://github.com/cross-lfs/lfs-arm

A couple of thoughts: quite possibly not grounded in full appreciation
off all the facts

1)
If, as is suggested in the discussion to date, JHALFS can still extract commands
from a CLFS book's sources and create a build environment, why not branch
that state off, maybe call it JHACLFS, and move forwards after dropping CLFS
support in the "main" branch.

2)
I'd formed the idea that parts of the CLFS approach, had been melded into
the current layout of the LFS build system, so does that mean that LFS now
actually has more similarity to CLFS, than it used to?

Indeed, IIRC, there was always a "path" through the CLFS Book that just built
a "single Arch" system, as in, one with no "Cross" elements, but you were just
doing more work than you needed to if you took that path.

If so, then, doesn't it just come down to the way  that the XML tags are
annotated, so that JHALFS knows which ones to ignore?

3)
The "hope" has to be that people, who still use the CLFS book, and
perhaps merely run a "make dump-commads" (?) on the sources, so as
to extract a set of build command files (rather than cutting and pasting
out of the rendered HTML) that can be applied to an updated set of
sources and patches, would be motivated to pick up the work needed
to automate it, within the JHALFS framework.


I think the question I am trying to formulate is: how close, to a
"single Arch" path through the last CLFS Book, is the current
layout of LFS, and could the current LFS layout be used
as basis for dropiing in" other end-target Architecure pathways,
as long as the way they were marked up didn'' make :the LFS
sources too unwiedly?

Or perhaps, as implied elsewhere in the discussion so far:
could the existng CLFS "pathways" be turned into LFS branches,
akin to the "multilib"  branch, so that the JHALFS parsing was
less different between the LFS and CLFS ?


As I say, just some random thoughts really.

-- 
http://lists.linuxfromscratch.org/sympa/info/lfs-dev
Unsubscribe: See the above information page