On Sun, Jun 8, 2014 at 5:50 AM, venkatakrishnarao ks < [email protected]> wrote:
Hello, > We have a considerably large build system that uses non-recursive make to > build same source for more than one hardware variant. Not every component > is built for all variants either. It is conditional sometimes, as in > Component X is built only for Variant MIPS, not for Variant ARM. > As this build system is non-recursive, the parse time is huge, but then it > flies off fast. It is neatly written. But, when it comes to incremental > builds, it is slow, which is where I think tup beats make. > > I'm trying to rewrite this build system using tup. I'm finding it > difficult to decide on how to organize my Tupfiles. > > 1. tup expects that files are produced in the same directory as that of > Tupfile. This in my opinion creates the following problems: > 2. Because we build more than one hardware variant, I cannot co-locate my > Tupfile in the same directory as the source file, because, I cannot produce > the generated object file in the same directory as I have to build for more > than one hardware variant and If I do, they overwrite each other. > 3. So, I think I'm forced to make copies of Tupfile for each source > directory, in a different directory for each hardware variant so that each > hardware variant gets its own sandbox dir for each source directory for the > stuff it generates. > > Alternatively, > I can have one big Tupfile per hardware variant OR a few big Tupfiles; > that compiles almost all source files to produce .o, .a, .so, or > application binary. > This isn't as organized as the first option. > > Are there other better ways? > Do you know any tup build system that cross-builds source by default that > I can refer while I rewrite ours? > > You can try to use the built-in variants feature (as long as you're not on Windows), which would look something like this: Tupfile: srcs += foo.c ifeq (@(TARGET_ARCH),MIPS) srcs += mips.c endif ifeq (@(TARGET_ARCH),ARM) srcs += arm.c endif : $(srcs) |> ... |> At the top-level, you create a tup.config file to select the variant: CONFIG_TARGET_ARCH=MIPS If you want to build both variants at the same time, you could do: mkdir build-mips echo 'CONFIG_TARGET_ARCH=MIPS' > build-mips/tup.config mkdir build-arm echo 'CONFIG_TARGET_ARCH=ARM' > build-arm/tup.config Then tup will build both, with the outputs separated into the build-mips and build-arm subdirectories. Another option is to roll-your-own variants, so your Tupfile might look like: TARGET_ARCH=MIPS include myrules.tup TARGET_ARCH=ARM include myrules.tup Then your rules could write to foo-MIPS.o and foo-ARM.o, so they could exist in the same directory. -Mike -- -- 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.
