Sean,
Sounds good.
Go for it. As you say, let's start out simple with just the doc stuff.
If that goes well, let's consider the other bits.
Dann and I have tossed a few ideas back and forth on better ways to deal
with the architecture bits, but hadn't considered this one. Here is a
summary of what I think is our best idea so far:
make.d/(x86|ppc|ppc64|ia64|x86_64).rul to create BOEL_NEEDS_THIS
dependency chains
The basic idea is that rather than trying to determine dependencies in
each thing that may possibly be built (uclibc, pdisk, etc.) that we
would do it once in a rule like, make.d/ppc64.rul. One of these rule
files would include the key contents of something like:
BOEL_NEEDS_UCLIBC=1
BOEL_NEEDS_PDISK=1
Then, in the pdisk.rul file, it would:
ifdef BOEL_NEEDS_PDISK
build it;
The <arch>.rul file could also define things like INITRD_COMPRESS, etc.
It hasn't been implemented yet (obviously) and I don't think we have our
hearts set on any particular solution. So I'll look forward to seeing
how the autoconf stuff works out. :-)
Cheers, -Brian
Sean Dague wrote:
>One of the major issues I see in trying to build SystemImager on many
>different Linux distros is that docbook2man works a bit differently in
>different places, and this is the #1 thing that breaks the build.
>
>Given this, it would be nice to be able to just turn off documentation
>generation, or auto configure it off on platforms where it isn't going to
>work.
>
>I'm happy to add a very basic configure script in the top level of
>SystemImager using autoconf, if other people are interested. It will start
>off not doing a whole lot (just this doc thing for now), but I think a lot
>of the build process could be adjusted to be a bit more user friendly in
>this way. Building with LVM would be another good candidate for this, as
>anyone not running a very current Linux distro doesn't have LVM headers.
>
>It would also be nice to purge some of the ARCH checks that are scattered
>everywhere through the code and replace them with real FEATURE declarations,
>like the INITRD_COMPRESS variable, etc.
>
>My thought is that configure would create a config.inc in the top directory,
>which lists everything it sets, and an explanation of what each does, in
>case someone wants to change things before running make, or configure gets
>it wrong, or whatever.
>
>Opinions welcomed.
>
> -Sean
>
>
>
--
------------------------------------------------------
Brian Elliott Finley Mobile: 630.631.6621
gpg --keyserver wwwkeys.pgp.net --recv-keys 10F8EE52
------------------------------------------------------
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Sisuite-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sisuite-devel
