From 4f63afc1177021d6345502892dbd028f5d6db5eb Mon Sep 17 00:00:00 2001 From: Boris Kolpackov Date: Mon, 16 Jul 2018 15:21:26 +0200 Subject: Implement in module Given test.in containing something along these lines: foo = $foo$ Now we can do: using in file{test}: in{test.in} file{test}: foo = FOO The alternative variable substitution symbol can be specified with the in.symbol variable and lax (instead of the default strict) mode with in.substitution. For example: file{test}: in.symbol = '@' file{test}: in.substitution = lax --- build2/in/target.hxx | 46 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 build2/in/target.hxx (limited to 'build2/in/target.hxx') diff --git a/build2/in/target.hxx b/build2/in/target.hxx new file mode 100644 index 0000000..90def2d --- /dev/null +++ b/build2/in/target.hxx @@ -0,0 +1,46 @@ +// file : build2/in/target.hxx -*- C++ -*- +// copyright : Copyright (c) 2014-2018 Code Synthesis Ltd +// license : MIT; see accompanying LICENSE file + +#ifndef BUILD2_IN_TARGET_HXX +#define BUILD2_IN_TARGET_HXX + +#include +#include + +#include + +namespace build2 +{ + namespace in + { + // This is the venerable .in ("input") file that needs some kind of + // preprocessing. + // + // One interesting aspect of this target type is that the prerequisite + // search is target-dependent. Consider: + // + // hxx{version}: in{version.hxx} // version.hxx.in -> version.hxx + // + // Having to specify the header extension explicitly is inelegant. Instead + // what we really want to write is this: + // + // hxx{version}: in{version} + // + // But how do we know that in{version} means version.hxx.in? That's where + // the target-dependent search comes in: we take into account the target + // we are a prerequisite of. + // + class in: public file + { + public: + using file::file; + + public: + static const target_type static_type; + virtual const target_type& dynamic_type () const {return static_type;} + }; + } +} + +#endif // BUILD2_IN_TARGET_HXX -- cgit v1.1