modules,Jamfiles, include-guards etc.

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

-Dave

+---------------------------------------------------------------+
David Abrahams
C++ Booster (http://www.boost.org) O__ ==
Pythonista (http://www.python.org) c/ /'_ ==
resume: http://users.rcn.com/abrahams/resume.html (*) \(*) ==
email: david.abrahams_at_[hidden]
+---------------------------------------------------------------+