Hi, Pete
> o Is it necessary to move the source modules up out of "src"? (I'd rather
> not reorganize the CVS repository if not absolutely necessary, plus
> I have a slight bias towards keeping the code in "src".)
This can be easily done. I just chose the standard package layout found in
most GNU based packages.
> o It looks like it builds the .o and binaries directly into the source
> directories as opposed to a separate (obj, lib, bin) area. Is it
> possible to continue to build into separate (obj, lib, bin) areas?
> (In particular with the "arch" subdirectory to allow different
> architectures to be built consecutively within the same source
> build.)
This is the behavior of autotools. I have added comments on how to make
multiple builds from the same sources in the INSTALL file:
You can create a directory for every separate build (e.g. debug build or
architecture). Go to that directory and invoke the configure script residing
in the sources directory. A package tree containing the specific Makefiles
will be created in the present directory. All object files will then reside
there. This is a real feature because every build directory can have its own
configure settings which are remembered.
> o The two solaris builds at SLAC (sol8 and sol9) fail during
> "./configure" with:
>
> configure: error: Could not locate openssl/opensslv.h in /usr/include
> It looks like this is in /usr/local/include at SLAC.
Directories where to find optional packages can be given by the
--with-FEATURE-inc / --with-FEATURE-lib options, if they are found in no
standard places. You can list all the options using the 'configure --help'
statement.
I will add /usr/local/ to the standard paths which to check.
> o It looks like the echo-ing of the compilation lines is on by default,
> this was an option previously.
Sorry, this is the usual behavior of autotools builds. The confusing part is
the many preprocessor options (-D*) in the command lines. This is usually
solved by having autotools generate a config.h file with the definitions
which then is sourced by all files needing access to the cpp options. We
can easily do this, but it requires a change to the source files.
> o For the Alice authorization package, we are happy to host this within
> the xrootd CVS for convenience even if that means some extra configure
> options. I think the important thing here is that those things are
> packaged separately (e.g. in a separate rpm/tarball, etc.) by the
> same build scripts.
Yes. That's what I was hinting at. This module will come in a separate
tarball. The configure script will take the xrootd source location as an
argument. We already have it working this way.
I'm now preparing the rpm template.
Cheers,
Derek
|