Boost logo

Boost-Build :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-03-31 20:56:08

Why are we creating a separate module in which to run tests whose name
is the same as the module's include-guard?

poke $(module-name) : __tag__ : $(module-tag) ;

module $(module-tag)
# Prepare a default behavior, in case no __test__ is
IMPORT modules : no_test_defined : $(__name__) : __test__ ;
module $(module-name)
# Add some grist so that the module will have a unique
target name
local module-target = [ modules.peek $(__tag__) : __file__ ]
module-target = $(module-target:G=module@) ;

Further, the setting of a single-valued __tag__ variable inside the
$(module-name) module seems to be in conflict with the stated purpose of
allowing files to be re-included.

Finally, as long as all of a project's Jamfiles are thrown together into
a single module "soup", what are we gaining by using modules.load to
read them? If it's just single-inclusion, I think a separate rule for
Jamfile inclusion is in order. Jamfiles need special post-inclusion
actions to construct the targets they specify, and finally, based on
Rene's arguments (which I accept)... they're not modules!

I am leaning towards strongly opposing this bit of generalization (the
new include-guard parameter) as it seems to add complication and
potential for bugs without real benefit.


David Abrahams
C++ Booster ( O__ ==
Pythonista ( c/ /'_ ==
resume: (*) \(*) ==
email: david.abrahams_at_[hidden]


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at