BLFS support in jhalfs

Hi,

A good BLFS support is the big pending issue for jhalfs, and
the most waited 
feature. Current implementation creates a not very
user-friendly Makefile and 
broken build-scripts for several packages, plus a lot of
other bugs. I don't 
want that code in jhalfs-1.0.

I'm thinking on a method to can generate sub-books to
extract from the scripts 
and Makefile needed to build only the package, plus its
dependencies, 
selected on command line. That method should to allow build
BLFS packages 
step-by-step in a linear way.

For example, for a desktop system, in the first run the user
could to build 
Xorg+dependencies, on a second run KDE+dependencies, then 
OpenOficce+dependencies. Of course, on each run already
satisfied 
dependencies must be skipped.

To implement that, specific BLFS code not related with
{C,H,}LFS code must be 
developed. IMHO, ./blfs should be a separate script and all
references to 
BLFS should be removed from master.sh and common/* files.

But implementing that is a huge task due that the book
should be parsed 
forward to solve dependencies. I'm not yet sure what tool,
XSL or a bash 
script, is the best to create such sub-books and how many
time we will need 
to develop the code.

On any case, I proposse to remove all current BLFS code from
trunk and start 
working on a new implementation on the experimental branch,
based on the 
above build method or on any other build method to be
propossed and 
discussed.


-- 
Manuel Canales Esparcia
Usuario de LFS nº2886:       http://www.linuxfroms
cratch.org
LFS en castellano: http://www.escomp
oslinux.org/lfs-es http://www.lfs-es.com
TLDP-ES:                           http://es.tldp.org
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

El Martes, 16 de Mayo de 2006 19:59, M.Canales.es escribió:

> I proposse to remove all current BLFS code from trunk
and
> start working on a new implementation on the
experimental branch, based on
> the above build method or on any other build method to
be propossed and
> discussed.

There is no comments about that ??

-- 
Manuel Canales Esparcia
Usuario de LFS nº2886:       http://www.linuxfroms
cratch.org
LFS en castellano: http://www.escomp
oslinux.org/lfs-es http://www.lfs-es.com
TLDP-ES:                           http://es.tldp.org
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

M.Canales.es wrote:
> El Martes, 16 de Mayo de 2006 19:59, M.Canales.es
escribió:
> 
>> I proposse to remove all current BLFS code from
trunk and
>> start working on a new implementation on the
experimental branch, based on
>> the above build method or on any other build method
to be propossed and
>> discussed.
> 
> There is no comments about that ??
> 

Sorry, I've had some other personal things requiring my
time and 
attention lately. If it's broken, and we're hoping to
release around the 
same time as LFS 6.2, then what you've outlined above seems
reasonable.

--
JH
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

El Miércoles, 17 de Mayo de 2006 23:19, Jeremy Huntwork
escribió:

> Sorry, I've had some other personal things requiring
my time and
> attention lately. If it's broken, and we're hoping to
release around the
> same time as LFS 6.2, then what you've outlined above
seems reasonable.

Yes, it's very broken.

I would prefer to release jhalfs 1.0 only with {C,H}LFS
support when releasing 
LFS-6.2 and hope to have ready the new BLFS support before
the next BLFS book 
release.

At this moment looks that I'm very near to can create
linear-build-order BLFS 
books. Remain an issue that I'm not try to solve yet. How
could I to dump a 
file in reverse line order?

Now I can create a file listing dependencies from the target
package up to its 
last dependency (just finished few minutes age the prototype
parser code). 
But we need listing they in build order, not as a
dependencies tree.

-- 
Manuel Canales Esparcia
Usuario de LFS nº2886:       http://www.linuxfroms
cratch.org
LFS en castellano: http://www.escomp
oslinux.org/lfs-es http://www.lfs-es.com
TLDP-ES:                           http://es.tldp.org
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

On 5/17/06, M.Canales.es <manuellinuxfromscratch.org>
wrote:
>
> I would prefer to release jhalfs 1.0 only with {C,H}LFS
support when releasing
> LFS-6.2 and hope to have ready the new BLFS support
before the next BLFS book
> release.

Not that I'm in charge here, but this seems like the right
way to go.
BLFS is an entirely different beast in that it's the only
one of the
books where dependencies must be tracked.  Unless you've
got solid
code for this, I think it's best to get the release out and
not suffer
bitrot on the working parts.

> At this moment looks that I'm very near to can create
linear-build-order BLFS
> books. Remain an issue that I'm not try to solve yet.
How could I to dump a
> file in reverse line order?

I can show you a simple dependency follower that uses make. 
Greg
Schafer posted it on DIY some time back, and now I use it in
my
scripts.  It's pretty simple and powerful.  It would
require some XML
parsing to dump the dependencies from the book into make
format, but
I'm sure you've got the XSL wizardry to pull it off. 

To me, the hard part is that the build instructions change
depending
on what dependencies are there.  Most of the time, the CMMI
packages
will handle this on their own, but some packages require
more manual
massaging.  For example, the build of firefox is very
different if you
have a system installed NSS/NSPR.

> Now I can create a file listing dependencies from the
target package up to its
> last dependency (just finished few minutes age the
prototype parser code).
> But we need listing they in build order, not as a
dependencies tree.

This is where make comes in handy.  Oh, I just remembered I
have this
on anduin.  Look in this directory

http://anduin.linuxfromscratch.org/~dnicholson/deps/

Here's a target in server:

subversion: pkg-config openssl neon expat httpd

deps.mk has a simple rule which tracks down all the deps
(these are
mine and are a little hairy because of an extra module in
PAM)

$ ./deps.mk subversion
pkg-config
openssl
Python
libxml2
neon
expat
mime-support
cracklib
cvs
glib2
Linux-PAM
cyrus-sasl
tcp-wrappers
openldap
pcre
httpd
subversion

Feel free to use it if you want.

--
Dan
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

El Jueves, 18 de Mayo de 2006 00:03, Dan Nicholson escribió:

> To me, the hard part is that the build instructions
change depending
> on what dependencies are there.  Most of the time, the
CMMI packages
> will handle this on their own, but some packages
require more manual
> massaging.  For example, the build of firefox is very
different if you
> have a system installed NSS/NSPR.

Actually, BLFS builds will not be full automatized.

My intention is to create an HTML book for the target
package with all 
dependencies (based on the selected level) in build order,
plus the base 
scripts for that packages.

Then the user must to review that book, wiki pages, etc..,
edit the required 
scripts, add/remove dependencies, and, when ready, then
re-run the script to 
create the Makefile.

That will be a helper tool that assist users to create their
own automatized 
BLFS builds.

> This is where make comes in handy.  Oh, I just
remembered I have this
> on anduin.  Look in this directory
> 
http://anduin.linuxfromscratch.org/~dnicholson/deps/

Thanks. I will see at that. Look like it is aware of
duplicated entries 
also )

-- 
Manuel Canales Esparcia
Usuario de LFS nº2886:       http://www.linuxfroms
cratch.org
LFS en castellano: http://www.escomp
oslinux.org/lfs-es http://www.lfs-es.com
TLDP-ES:                           http://es.tldp.org
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

On 5/17/06, M.Canales.es <manuellinuxfromscratch.org>
wrote:
>
> Actually, BLFS builds will not be full automatized.
>
> My intention is to create an HTML book for the target
package with all
> dependencies (based on the selected level) in build
order, plus the base
> scripts for that packages.
>
> Then the user must to review that book, wiki pages,
etc.., edit the required
> scripts, add/remove dependencies, and, when ready, then
re-run the script to
> create the Makefile.
>
> That will be a helper tool that assist users to create
their own automatized
> BLFS builds.

Your an ambitious man, Manuel.  I'll be interested to what
how this looks.

> > This is where make comes in handy.  Oh, I just
remembered I have this
> > on anduin.  Look in this directory
> > 
http://anduin.linuxfromscratch.org/~dnicholson/deps/
>
> Thanks. I will see at that. Look like it is aware of
duplicated entries
> also )

correct order + remove duplicates = saves me a lot of effort

Actually, I've thought about writing my own code for this a
bunch of
times, but that way is just so easy!

--
Dan
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

El Jueves, 18 de Mayo de 2006 01:15, Dan Nicholson escribió:
> On 5/17/06, M.Canales.es <manuellinuxfromscratch.org> wrote:

> > That will be a helper tool that assist users to
create their own
> > automatized BLFS builds.
>
> Your an ambitious man, Manuel.  I'll be interested to
what how this looks.

Well, the code to create LFS-style linear build order BLFS
books for a target 
package is now in the experimental branch.

Copy all files under BLFS/ to an empty dir. On that dir,
copy or "svn co" a 
directory containing the BLFS book sources.

Run 

./packages.sh <BLFS_sources_dir_name>

Then run, for example,

./blfs-render.sh gnome-media 3

Wait 3 minutes and see the results 

The generated books are almost the best that can be done
with the current 
dependencies listed and tagging used (some dependencies
don't have the 
required role attributes, some point to the wrong file,
circular 
dependencies, issues with alternative packages, etc...)

If there is real interest in generating such type of BLFS
books (for general 
use, not only to support jhalfs) a thread in blfs-dev shoul
be started to 
address that issues.

The code is yet a little ugly, but I hope that George could
help cleaning and 
improving it.

> > Thanks. I will see at that. Look like it is aware
of duplicated entries
> > also )
>
> correct order + remove duplicates = saves me a lot of
effort
>
> Actually, I've thought about writing my own code for
this a bunch of
> times, but that way is just so easy!

Instead using deps.mk I solved that issues using sed and
tac, plus reusing the 
output from already resolved packages dependencies.

That was to improve global parsing speed and to track
circular dependencies, 
something not easy to do when triying to auto-generate a
deps.mk script.


-- 
Manuel Canales Esparcia
Usuario de LFS nº2886:       http://www.linuxfroms
cratch.org
LFS en castellano: http://www.escomp
oslinux.org/lfs-es http://www.lfs-es.com
TLDP-ES:                           http://es.tldp.org
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

El Martes, 23 de Mayo de 2006 21:24, M.Canales.es escribió:

>
> ./blfs-render.sh gnome-media 3
>

 ./blfs-parser.sh gnome-media 3

Sorry.

-- 
Manuel Canales Esparcia
Usuario de LFS nº2886:       http://www.linuxfroms
cratch.org
LFS en castellano: http://www.escomp
oslinux.org/lfs-es http://www.lfs-es.com
TLDP-ES:                           http://es.tldp.org
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page