Arvind Srinivasan wrote:
> Hi,
>
> When building the SFW sources, I noticed that the apache component
> has a bootstrapping issue in that usr/src/cmd/apache depends on
> /usr/apache/bin/apxs.
that's somewhat a bug yes, though sometimes it's not possible
to use the one in the proto area depending on what you are building
(since it might not run on your build machine. That's usually a larger
problem in ON though).
However it's not like we don't have occasional issues like this
even in ON - sometimes you need the latest linker before you can
build other things, and how much do you really want to rebuild
natively so you can use it safely?
> I found it strange that the apache component build depends on Apache
> already being installed on the build machine. (I think this is due to
> the fact that the apache component contains other components and
> these components depend on apxs.)
to be picky, lots of stuff in the build of sfw requires sfw bits
on the build machine. you just don't always need them to be the
latest ones, nor do you necessarily think of them (libz, libxml2
and such otherwise you don't boot .. but that is picky :)
> Which brings me to my next observation....
>
> I also noticed that while most directories of usr/src/cmd have just a
> single .tar.gz, there are a few which have multiple .tar.gz files.
and there's one that combines what should be at least two tar files
in one (sma). That's the one I don't like, but I'm fixing that, as
it also is bloating things in the gate.
> Am I correct in assuming that the guideline/decision to keep every
> component as a top-level component (and specifying build dependencies
> between components in usr/src/cmd/Makefile) was made sometime after
> these 3 components were integrated into the SFW build tree?
no. that guideline was started with the ccd, long before sfw was
created. But remember, it's a guideline not a rule. You can check
all the sources in if you like (though it's not really wise).
The goal is that it's flexible, so you can do whatever you think
is the minimum needed to integrate and keep up to date with
future revisions. Though also think about what future maintainers
may need to know in order to update your thing when you're gone
or uninterested - they may not be happy having to understand that
most things build one way but this piece has Joe's Different
Build System (New and Improved).
>
> What should one do with multiple versions of the same component with
> respect to where they should be in the source layout? In the current
> tree, there are 2 versions of mod_perl in 2 different directories [i]
> % ls */*.tar.gz | grep mod_perl apache/mod_perl-1.29.tar.gz
> apache2-modperl/mod_perl-2.0.2.tar.gz [/i]
It depends on the maintainers choice and how difficult it is
to build and install them at the same time. I don't know why
the mod_perl's are split but hopefully there was a good reason.
Possibly the one sch suggested.
>
> As more components are integrated into SFW, there might be other
> cases where more than 1 version of a component needs to be in the
> tree. For such cases wouldn't it be better to have all the versions
> under the same top-level directory? i.e.
>
> [i] mod_perl/mod_perl-1.29.tar.gz mod_perl/mod_perl-2.0.2.tar.gz [/i]
It might be. Again, it depends on the maintainer and how hard or
confusing it would be to build both in the same place. Both today's and
tomorrows maintainer. And experience can lead to a reorg if necessary,
such as when postgres went in one way then changed later.
Though I know when editing Makefile.sfw's that build multiple components
I usually edit the wrong bit a few times, but maybe that's just me.
Mike
