Jim Gifford wrote:
This script is
available at http://ftp.jg555.com/headers/headers.
What I ask from the more advanced members of LFS and CLFS is to give
them a try, comment on them. Would they be useful to use as a temporary
alternative. a viable alternative, hard to maintain, or is it a waste of
time?
This begs a question. What the hell are the libc developers using for
userspace headers? And why can't they share?
Unfortunately, I think we're going to need a more long term plan. Your
script is a very impressive jump start on that plan! I did exactly the
same thing with the u{8,16...}, __u*, ____u*, and back to __u* in my
lastest attempts to reduce the size of my working diffs. :-) It's a bit
silly, but it works!
So is it finally time for LFS's Libc Headers project? LFSLH? :-)
I recently tried to work from the base 2.6.12 kernel headers, diffed and
merged with LLH and jump strait to 2.6.15.4 kernel headers along side
the llh set. Needless to say, I threw up my hands in total frustration.
new mtds, scsi, even IDE and i386 were easy, but I was _way_ out of my
league jumping two tiny versions and 4 points in the linux directory
with several new files. For once, Google didn't have an answer I could
use. :-)
For someone who is familiar with the kernel, I really don't think it'll
be all that big of a deal to work up a current set if you do it
incrementally by point release working from the diffs and current LLH.
Maybe even work only
minor...last point, next minor...last point...
against partially sanitized headers (with Jim's script).
Another very minor point is trying to find a way to rip out all the
__KERNEL__ portions (which in turn removes quite a few of the files
included in the tarball. This isn't easy, or even necessary but in
combination with Jim's script, it would again, greatly reduce the size
of the diffs between new versions. Counting line by line, making note
of line numbers that contain #, greping for if, el, end, __KERNEL__
and the like. then filing them away on those line numbers to get a
matched count sounds really time consuming for
bash/sed/grep/cut/head/tail. Anyone have a more creative method? Again,
however, these are safe to leave in place...it's just a waste of space,
and a very minor (is it even measureable?) waste of compiler time being
in the userspace headers.
Last, run Alexanders test case and generate a report of failed files for
manual intervention. I have no idea what kind of shape resultant files
are in ATM. I will toy with the idea in a couple of days so that maybe
I can compose a more factual and less opinionated message.
-- DJ Lucas
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
