Remove Boost

[GoogleCodeExporter]

HadesMem was awsome, but now when I do a checkout, I have to download boost... 
I understand you want users to only use a certain version of Boost, but some 
people have already built boost into a specific directory that they like (for 
example I built it on my external HD). It would be a real inconvenience to have 
to go through HadesMem and change the location of where boost was installed, 
have to download boost every time there is an update, and/or have two boost 
builds on your computer.

Original issue reported on code.google.com by aidan.b....@gmail.com on 22 Jun 2011 at 5:48

[GoogleCodeExporter]

All you need to do is change Jamroot to point the Boost project to your own 
dir. It's a one-line change in the build files.

Also, only a specific revision of Boost is installed, so you don't have to 
download it every time Boost is updated, only every time I feel it's worth 
updating.

Having two copies of Boost is a pita I guess, but as long as you just change 
your Jamroot to point to your 'local copy' then you won't be building from the 
secondary one so the space used up is fairly negligible (imo).

Sorry, but I'm not going to cause a potential build system breakage in the 
future for this (being able to pull down and compile back versions quickly and 
easily is important for testing). Especially once I finish the current rewrite 
and API finalization and enter SemVer.

Unless you can come up with a solution that will keep everybody happy?

Original comment by raptorfactor@raptorfactor.com on 22 Jun 2011 at 3:16

• Changed state: WontFix
• Added labels: Priority-Low, Type-Other
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Actually, how about an environmental variable? I think (I'd have to check) I 
could check for the existence of an environmental var (like 
HADES_ALTERNATE_BOOST) and if it exists, use that instead of the local copy?

You'd still have to pull down Boost as part of the subversion checkout, but at 
least then you wouldn't have to hack Jamroot (even if it's only a one-liner).

Original comment by raptorfactor@raptorfactor.com on 22 Jun 2011 at 3:17

[GoogleCodeExporter]

That makes a lot more sense to me, thanks for clarifying.

The environment variable could be a good idea I guess, but actually I would 
prefer to edit the Jamroot file. I didn't even know I was supposed to edit that 
file, so now I actually think your build system is great how it is.

Also, this is a little off topic and just a question I have regarding the 
user-config.jam file in the Misc directory; should we move that file to the 
root directory of the trunk, or does boost know to look in the Misc directory?

Original comment by aidan.b....@gmail.com on 22 Jun 2011 at 6:11

[GoogleCodeExporter]

The user-config jam file belogs in either your user dir, or the boost root, but 
at the moment Hades doesn't require it. It may in the future when I set up 
Quickbook, but I'm hoping to avoid that by packaging the XML binaries and just 
compiling Quickbook as part of the build process.

Original comment by raptorfactor@raptorfactor.com on 23 Jun 2011 at 6:00

[GoogleCodeExporter]

Just a quick update, I've managed to set up the build system in my rewrite so 
that the documentation tools can be run without user-config hacks, so my 
original advice still applies (i.e. you can ignore that file in /Misc -- I'll 
delete it now, thanks for reminding me). :)

Original comment by raptorfactor@raptorfactor.com on 26 Jun 2011 at 6:45

[GoogleCodeExporter]

Cool

Original comment by aidan.b....@gmail.com on 4 Jul 2011 at 2:19