Daryle Walker wrote:
On 2/2/06 12:16 PM, "João Abecasis" <[EMAIL PROTECTED]> wrote:
You mean you never got the doc sample I posted working?
No.
:(
I guess, for the sample, I assumed you would have everything set-up for
building docs *inside* the boost tree. In case you're still interested,
I'll give a few more details...
There's a setup script for BoostBook in
BOOST_ROOT/tools/boostbook/setup_boostbook.sh, for POSIX systems.
There's a python version as well, but there's a comment saying it is
incomplete at the moment.
This script checks for the presence of DocBook stylesheets and DTD,
xsltproc, doxygen, java and fop (to generate PDFs). It downloads DocBook
stuff and fop (if java is installed) and it sets up the necessary
configuration in $HOME/user-config.jam
For quickbook docs you still need to "register" a compiler with
Boost.Build. That could be as simple as adding the following to
$HOME/user-config.jam
using gcc
: [optional-version]
: [optional-path-to-non-default-executable]
: [optional-options]
;
I think there are plans to make this registration automatic before the
1.34 release.
Of course, this is all on top of the bjam and BOOST_BUILD_PATH issues
you have figured out before.
Is bjam IDE friendly? I use an IDE (Xcode) to create my programs. Why
would I need bjam to compile my Boost files when I can get my IDE compiler
to do it directly? (For large-scale development, having to use bjam could
be difficult for compiling if you have already set up everything else
through an IDE project file.) I use Boost through CVS (and the Sandbox
CVS), so I can't use bjam to create Boost libraries in advance, since they
could need a re-build after any CVS update. (I also want to keep any Boost
files private to my user account.) Using the IDE to manage Boost files
ensures that the compilation options always match your main files and that
you don't get library combinations (static vs. dll, single vs.
multi-threaded) that you don't need.
Since you already have Boost setup in Xcode, the easiest way would be to
add quickbook's sources in there as well.
For bjam to better interact with Xcode we'd need one of them to
understand the other's files/options. FWIW, googling around I found
someone's report of tricking Xcode with a makefile project and
instructing it to use bjam instead of make. It's still not a complete
solution because makefiles and Jamfiles are not synchronized...
The advantage of using Bjam and Boost.Build is probably more significant
to people using multiple compilers or supporting multiple platforms.
When using bjam there's no need to install to a system location, or even
to build all of boost in all variants at once. Over here, I keep all of
Boost private to my account as well. To build quickbook from
BOOST_ROOT/tools/quickbook together with dependencies, I run
bjam --v2 release gcc
This brings all dependencies (and only those) up-to-date and nothing
gets (or was) installed in global system locations.
The same approach works from external projects by setting BOOST_ROOT
and/or BOOST_BUILD_PATH appropriately. But I won't recommend this before
you have the basic setup working and are comfortable with it.
Regards,
João
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Boost-docs mailing list
[email protected]
Unsubscribe and other administrative requests:
https://lists.sourceforge.net/lists/listinfo/boost-docs
