encodr, I like many aspects of your approach to variants. However, this design forces all variants to be built, when 'tup' is issued at the top level.
All that developers really need (besides variants to work on Windows), is to access the values of the config variables in each variant's tup.config, and then write their own custom rules based on those variables. Then they can do creative stuff like you just did, but leverage Tup's ability to request only 1 variant, or all variants in a single build invocation. Cheers, Ben On Sunday, September 29, 2013 2:46:51 PM UTC-7, encodr wrote: > > Variants as provided as a feature of tup appear to have limitations that > some might find inconvenient. > > However, there is a way to > * build variants in any part of the project tree, not just the top level > * keep individual sources inside variant (output) directories, if you want > * run on any platform? (perhaps; I haven't actually tested this on windows) > > Let's say the subtree containing variants is in a directory > e..g MASTER/ > then the master has its own set of tuprules: > 1) MASTER/Tuprules.tup > * might define a variable indicating where sources are kept. > e.g. SRCDIR=$(TUP_CWD)/src > * might define macros like !cc and !link > * might define variables containing lists of interesting sources, > e.g. MAINSRC="$(SRCDIR)/main.c, $(SRCDIR)/libfoo.c" > > 2) sources live in a directory below MASTER > e.g. MASTER/src/main.c > MASTER/src/libfoo.c > > 3) most of the build instructions that you would expect in an output > Tupfile are held in one file below the MASTER, > e.g. MASTER/shared.tup > (However, note that no output is created immediately below MASTER/ ) > > 4) within shared.tup, the variation in instructions is governed by switches > e.g. for each of many features like FEATURE_X > ifeq( $FEATURE_X_ENABLED), true) > ... modify a variable, or execute a buildrule, or whatever you need > endif > > 5) the output for each of the variants will be in a directory beside > shared.tup, > and each variant has its own Tupfile > e.g. MASTER/variant_A/Tupfile > > 6) Each variant Tupfile makes use of the rules expressed above, > and sets switches to govern how its own particular variant output will > be constructed > e.g. > include_rules > FEATURE_X_ENABLED=true # > FEATURE_Y_ENABLED=false # > for example > FEATURE_Z_ENABLED=false # > include ../shared.tup > > 7) If any variant has significantly different outputs, then > a variant/ directory can store its own sources; > a variant/Tupfile can have additional rules apart before or after > those acquired from ../shared.tup > > The resulting behaviour is that each variant directory appears to have a > shared set of instructions, but different features are enabled. > The outputs are created in the variant directories, beside each Tupfile, > as you would expect. > Otherwise, none of the various directories are "special"; any part of the > tree can contain variant things. > > This ability to build variants "without tup variants" has been present for > a long time. > I find it very useful. In fact, I have never tried to use the "official" > variant feature at all. > (Am I missing something?) > > Anyway, enjoy. > > e > > --- > for reference: > MASTER/ > src/ > foo.c > Tuprules.tup > shared.tup > variant_A/ > Tupfile > variant_B/ > Tupfile > > > -- -- tup-users mailing list email: [email protected] unsubscribe: [email protected] options: http://groups.google.com/group/tup-users?hl=en --- You received this message because you are subscribed to the Google Groups "tup-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
