* Arvind Srinivasan <arvi.srinivasan at sun.com> [2007-07-24 07:03]: > 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.) This is a bug. As Dermot points out, you should use the one you create in the proto area, or in the local directory.
> 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. > [i] > apache/ApacheJServ-1.1.2.tar.gz > apache/apache_1.3.37.tar.gz > apache/jserv-makefiles.tar.gz > apache/mod_perl-1.29.tar.gz > apache/mod_ssl-2.8.28-1.3.37.tar.gz > apache/webapp-module-1.0.2-tc402.tar.gz > [/i] > [i] > subversion/subversion-1.4.3.tar.gz > subversion/swig-1.3.28.tar.gz > [/i] > [i] > webmin/Authen-PAM-0.14.tar.gz > webmin/Authen-SolarisRBAC-0.1.tar.gz* > webmin/IO-Tty-1.02.tar.gz > webmin/Net_SSLeay.pm-1.30.tar.gz > webmin/webmin-1.340.tar.gz > [/i] > > 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? For Apache 1.x, yes. For Subversion, it's because swig is a private subcomponent. For webmin, again, it's because these Perl modules are private subcomponents--they don't deliver into the /usr/perl5 hierarchy. > 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] We can check, but this is probably because the build methods for mod_perl differ between Apache 1.x and Apache 2.x. I remember various 1.x modules needing access to the Apache source tree as part of the build... The engineering point is that there is a tradeoff between maintaining a convention and coercing the build to do something unusual to support that convention. > 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] I like Dermot's answer here--but I wouldn't reorganize the Apache 1.x tree without further reasons... - Stephen -- sch at sun.com http://blogs.sun.com/sch/
