Skip to content

Support out-of-source builds #39

Open
mathstuf opened this Issue Nov 3, 2011 · 15 comments

9 participants

@mathstuf
mathstuf commented Nov 3, 2011

It would be nice to be able to have tup build a project without touching the source tree. After using CMake for years, it's something I've grown accustomed to (for one, it allows one source tree to have multiple build trees for different compilers or options). I managed to hack bootstrap.sh to work, but it ended there.

@gittup
Owner
gittup commented Nov 3, 2011
@majewsky

+1 on this idea. There may be other things which need to be implemented in tup to make it a suitable backend for CMake, but this functionality needs to be available before one can even start thinking about a CMake backend.

@gittup
Owner
@majewsky

That's absolutely marvelous! I honestly don't understand why you didn't merge this into master right away. I've just used this branch to compile tup (both in-source and out of source) and checked that the compiled binaries pass the test suite on my Linux system.

@zjg
zjg commented Apr 19, 2012

I tried the out-of-tree branch with my large project at work (~300 Tupfiles), and it worked fine without any extra fiddling.

The only problem I ran into so far was when I accidentally deleted some directories in the build tree; tup complained with "tup error: Unable to open directory for update work."
After manually re-creating the directories, tup was happy again.

@gittup
Owner
@gittup
Owner
@gittup
Owner
gittup commented May 26, 2012

The variants branch has been merged, which essentially allows building outside of the source tree. It should also handle the case of accidentally removing directories in the build tree by recreating them if necessary.

@eddyp
eddyp commented Aug 19, 2013

Does the already merged code support build variants to any degree?
For projects building for several compilers and platforms this would be really necessary.

@ppannuto

Yes, variants are well-supported / well-tested / well-documented at this point.

This issue should probably just be closed.

@eddyp
eddyp commented Aug 19, 2013

I've looked over the manual, but I find the variants support very limited. I work with a project where there are usually between 500 to 2000 variants of the project because there are some hard requirements to have the system statically configured. These variants are necessary to test the required features in the finished product, so having them all at the same level as the .tup directory is quite unfeasable. Instead we use a directory structure organized in groups and subgroups, is it's a tree of variants.

How hard would it be to support such a monster ? :-)

@FreddieChopin

Yes, variants are well-supported / well-tested / well-documented at this point.

... on every system but Windows, where they simply don't work at all (;

@eddyp
eddyp commented Aug 22, 2013

This is exactly where I need this to work :-( . I hope I'll have the time to try to make it work somehow on one of the projects that seems more closer to what tup can handle ATM...

@cppmaven

I also need a tree of output variants as well. And like eddyp, it is quite unfeasable to place these inside the Tup hierarchy.

I can manage organizing the structure, by writing rules myself in Tup or LUA. I only need the generic ability to access files outside the Tup hierarchy. This ability would make Tup more flexible, allowing developers to customize it ways to solve their unique problems, given their unique organizational constraints.

The variants implementation is convenient, but not flexible enough for me to use.

@pradyunsg

Bump.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.