using system libs for extern deps on linux build

[Angel]

Hi all,

I am trying to get together a chef "cookbook" for downloading and
building the TPP on a linux system. (Chef is an open source systems
administration, bootstrapping and configuration system from
opscode.com).

I would be nice to separate out some of the pieces into their own
"recipes", especially the external dependencies such as boost and
pwiz. In older TPP releases you could set the BOOST include dirs in
Makefile.config.incl, but it looks like 4.3.1 only allows override of
certain vars:

TPP_ROOT
TPP_WEB
XSLT_PROC
CGI_USERS_DIR
PERL_LIB_CORE
BZ2_LIB
LIB64

Two questions:
1) is anyone else working on a chef recipe for TPP and can share?
2) alternatively are the TPP undergoing any sort of re-engineering of
the build to be more modular, specifically with respect to pwiz and
using pwiz' own bjam build process instead of relying on an older SVN
external revision of pwiz and building that?

I mean I can always fake it by building boost and pwiz, then copying
the needed shared libs to where the TPP build process expects them to
be, but that in and of itself will take some time to figure out an may
be a dead end. Help?
-angel

[Natalie Tasman]

Hi Angel,

I'm not familiar with "Chef", but I am working on exactly this kind of
build process re-engineering. For various reasons (which I can detail
if interested,) I've decided to go with the "tried and true" autotools
system, and you can see the work that I'm doing in tpp's SVN under
branches/autotools. My philosophy is to use system libraries when
available, and provide options to download and build locally when not
(for example, mingw.) My test platforms have been mac os x 10.5,
ubuntu 8.04 and 9.04, Centos 5.2, and mingw32/msys. I'm in the final
stages of getting mingw working, I still hope to generate an apache
config section from the user-specified install directories, and the
help text still needs improvement for clarity, but the core
functionality is mostly there.

It's not quite ready to introduce, and thus, I haven't checked in
./configure and other files, though you can easily try it yourself by
checking out autotools/tpp and running "autoreconf && ./configure &&
make" in the top level directory. For now, you may need to run
./configure a few times to get all the options for your system-- with
feedback, I hope to make this as automatically as possible. You can
run "./configure --help" to see some possibilities. (Note that as a
developer, you'll need autoconf 2.64; you may need to install this
yourself as it's not packed on all the systems I've tested yet, but
it's an easy install from source. Users will have no such requirement
and will just run the ./configure script when it's ready for
distribution.)

Regarding pwiz and bjam:

- source code: because pwiz is a very active project, and is
increasingly a key dependency of the TPP, it's important for us (in
TPP world) to have a version that we know is stable both in build and
specific functionality. So it's not likely that we'd tie pwiz's
latest trunk into TPP trunk. If you're asking about using svn-extern
linkage, I disabled that because it's just too slow, at least using
SVN; it was taking minutes for my continual build system just to
verify that TPP code was up to date.

- pwiz build system: we (Brian and I) intend to stay with our non-bjam
build for pwiz. This summer Brian wrestled with using pwiz's own
build system, but found that at least a few months ago, it was too
much in flux and too difficult to get working at that time. So we've
taken the stable subset that we need and support, and make sure that
builds for us.

I'd welcome any constructive feedback from you or any other interested
developer.

Natalie

[Angel]

autoconf is a welcome change. It will fit in nicely with what I am
doing. I'll check out the branch and let you know if I run into any
gotchas.
-angel

On Nov 11, 1:58 pm, Natalie Tasman <natalie.tas...@insilicos.com>
wrote: