It seems variants feature explained in manual is not working on win32. Tup detects variant directory and reports any issues in config file, but when running "tup upd" no targets are built at all.
Is there anything planned for this? This feature is very much desired.
Out-of-tree builds (with variants) is a highly anticipated feature for Windows (; I'm waiting too (;
Yeah, this would be awesome. Currently a blocker for just plain switching over to tup.
something new on this issue or a hint where to look for the error in the source?
It would be great to have variants (actually I mostly care about out-of-tree build) in Windows (; Today I've thought about converting another project to Tup, but the vision of hundreds of object files all over the place made me write this post (;
I'd gladly look into this. A hint would be nice though.
Here's a message from Mike explaining what the problem is
@freddiechopin Thanks! I'll start digging around the tmp-file-tree branch.
I chickened out
I'm using a configure script (only a few lines of bash/batch) and building in-tree. It works fine except for the required rebuild when I reconfigure. It's not really an issue though, as I have a server build my release binaries for shipping.
Hi, I also have an immutable source tree, and all output is placed in another output tree, and then the release step puts its contents into yet another tree. I am looking forward to this on Windows 64-bit as well.
Also, I am completely dead in the water with TUP right now, I can't even call the shell command 'copy', as it is 64-bit on my machine. :(
But TUP's design rocks, so I'll wait. :)
First of all - much of variants functionality can be replaced with tup's ability (more recent than this issue) to output files to different folder (not only the one where the Tupfile is located).
As for the 64-bit tools, you can always use any coreuils package for Windows (like msys, gnuwin32, etc.), which is 32-bit. Personally I use this one - https://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/
I agree that the ability for a rule to write to an arbitrary location, is more flexible than the variant implementation, and as such I am not planning on using variants. I will use variable expansion in Tup or LUA to write the rules I need.
However, unless I am mistaken, all output must be in or below the directory containing the .tup directory. Is this correct?
I know I can symlink out to other locations for the purpose of building distinct output trees, and creating releases and installers on the network.
But I would rather express the actual location directly in the tup rule, instead of hiding behind symlinks. Did I miss some capability in Tup, is this limitation real or imagined?
Yes - this limitation still remains, but I really see no value in adding such support in tup if that's not trivial... I haven't given this much thought, but for me the combination of make and tup solve this pretty well. Tup is great in compilation, so why try to force it to do steps that are not related to compilation (like copying)? Just have this in your Makefile:
Now tup does the compilation, and you can add all non-compilation steps you wish that are not easy with tup but trivial with make - unit tests, installation, configuration, running scripts, flashing chips, ...
If you compile to ONE output directory (I usually use ./output) then you can even have the beloved "clean" rule. Actually if you'd generate the list of all generated files (using groups?) then you could implement "clean" in all cases...
I will consider wrapping Tup in Make as you suggest, for steps which do not produce immutable output. This could include running scripts, flashing chips, installation, but not producing the installer or running unit tests.
I view Tup as good at much more than simply compilation. Tup is good for any problem, which requires transforming inputs into immutable outputs. I view it as basically pure functional programming. Those outputs become inputs to functions, which then produce new immutable outputs. And so on, and so on.
My compilation outputs are inputs to a function which assembles a collection of files for release. That assembly is input to a function which produces a product installer. Unfortunately for me, these steps involve files which are outside the Tup hierarchy. I'll get along with symlinks, or use another tool, but Tup really is the best tool for this job. :)
Can't you assemble these files "in" tup hierarchy, do whatever you want to do with them and then - with make - delete all of that, configure new variant and start over with tup?
Edit: OK, I get it - you need to read additional files that are outside...
Here are the challenges and constraints I face in adapting a build system:
1) The build time for one variant takes ~4.5 hours.
2) There are about half-a-dozen build variants which a developer may want/need to use.
3) We want to integrate 'continuously'.
I need to keep all variants which have already been built, so a developer can switch between them quickly. That is why I desire out-of-tree builds. It is the power of Tup's incremental build, across multiple variants, which promises to solve this pain point. I will continue to explore...