 |
 |
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