Tup hierarchies inside tup hierarchies
Ricardo Correia
I am trying to use tup in a program that I'm working on, but I'm having one problem.
I'd like to bundle the source code of tup inside my project, so that anyone who wants to build my program doesn't need to install tup in their system.
This is a relatively common practice because not only it removes one build dependency, but it also makes sure that in case the authors of the build system need to make backwards incompatible changes, the program will still build correctly regardless of which version of the build system is installed in the system.
In any case, everything was going relatively well, as I only needed to make a one-line change to fix one issue [1].
However, as soon as I tried compiling my program, I noticed that tup considers all Tupfiles in the tup hierarchy to belong to it, even if they are apart of another tup hierarchy inside the first one.
To clarify, here's a visual representation of my directory structure:
$myprog/ -> root directory of my program (root dir of my tup hierarchy)
$myprog/.tup -> hidden .tup directory of my program
$myprog/Tupfile -> a Tupfile belonging to my program
$myprog/tup_src/ -> root directory of the tup source code (root dir of tup's own tup hierarchy)
$myprog/tup_src/.tup -> hidden .tup directory of tup, creating during ./bootstrap.sh
$myprog/tup_src/Tupfile -> Tupfile belonging to tup
$myprog/src/Tupfile -> another Tupfile belonging to my program
...
Now, the problem is that if I run 'tup' in the root directory of my program, it will also include tup's own Tupfiles and it will try to compile tup again. This led to a failure [2].
So I wonder if there's any way to ignore Tupfiles that are inside other tup hierarchies, or if such a configuration option could be added?
I don't really care that 'tup' builds itself again after I build it for the first time, although I guess that would also be OK as long as everything worked transparently (e.g. if tup wouldn't include my Tuprules in tup's Tupfiles).
[1] Since $myprog/tup_src is not a git repository, the 'git describe' at the end of tup's Tupfile seemed to fail due to a missing chdir() implementation in tup-ldpreload.so.
I just fixed this problem locally by changing "version=`git describe`" into a hardcoded value corresponding to the tup version that I imported into my program's repository: "version="v0.3-148-ge66f2dd"".
[2] This is the failure that I observed when trying to run "tup upd" in the root directory of my program:
[ tup ] Scanning filesystem...0.006s
[ tup ] No tup.config changes.
[ tup ] Parsing Tupfiles...
[ 0/27 ] .
[ 1/27 ] tup_src
Error: Attempting to insert 'ldpreload.o' as a generated node when it already exists as a different type. You can do one of two things to fix this:
1) If this file is really supposed to be created from the command, delete the file from the filesystem and try again.
2) Change your rule in the Tupfile so you aren't trying to overwrite the file.
Error parsing Tupfile [630] line 4
Line was: ': foreach *.c'
- [630] tup_src/src/ldpreload
Error parsing Tupfile [6] line 6
Line was: ': src/ldpreload/*.o'
- [6] tup_src
For the record, it builds fine if I do "cd tup_src && tup upd".
Thanks,
Ricardo
Mike Shal
The Tupfiles/Tuprules.tup files are limited in such a way that it
should always be possible to compose a superproject using subprojects
that individually build with tup (though there may be issues with
conflicting variables, as you alluded to). This is why tup doesn't
define a TUP_ROOT variable that points to where the .tup directory is
initialized, but instead forces you do define your own _ROOT variables
using $(TUP_CWD) (which is always relative). For example, you can
build tup by running 'tup init' inside the tup/ directory, or you
could run 'tup init' in a directory above tup, and it will still build
successfully.
However, tup assumes there is only one database for the whole project.
It is not able to compose multiple databases (that would probably be a
nightmare given tup's implementation). Although it could probably
ignore subdirectories that have .tup directories in them, you'd drive
yourself crazy trying to remember in which subdirectories you have to
run 'tup upd' in order to update things.
There are two options I would suggest trying - I don't know what other
issues you might encounter with them:
1) Keep tup as-is, and move the top of your project down one level (so
you'd have tup_src/.tup, and my_src/.tup)
2) Change tup's bootstrap.sh so it doesn't run ./build/tup init and
./build/tup/upd. You would just end up with the bootstrapped tup in
tup_src/build, and you should be able to have a single .tup directory
under $myprog.
I'd like to know what you end up doing. Also, did you encounter any
specific issues with the Tupfiles under tup_src including the
Tuprules.tup file from your main project?
>
> [1] Since $myprog/tup_src is not a git repository, the 'git describe' at the
> end of tup's Tupfile seemed to fail due to a missing chdir() implementation
> in tup-ldpreload.so.
> I just fixed this problem locally by changing "version=`git describe`" into
> a hardcoded value corresponding to the tup version that I imported into my
> program's repository: "version="v0.3-148-ge66f2dd"".
Even though it doesn't support chdir(), the git describe would
probably still fail (since git is just searching up the tree for a
.git directory). Are you using git for your project? If so, you can
make tup's git repository a submodule of your main git repository.
-Mike
Ricardo M. Correia
The Tupfiles/Tuprules.tup files are limited in such a way that itshould always be possible to compose a superproject using subprojects
that individually build with tup (though there may be issues with
conflicting variables, as you alluded to).
If you make that design decision (which sounds interesting to me), then there needs to be a solution for the conflicting variables.
It's entirely possible (and likely) that two completely separate projects use the same variable names (!cc macro, or CFLAGS variables, for instance).
However, tup assumes there is only one database for the whole project.
It is not able to compose multiple databases (that would probably be a
nightmare given tup's implementation).
This may be a stupid idea, but what if tup would always try to go up the directory tree up until the root directory (/) trying to find a database, so that it always finds the topmost one, regardless if there are others in-between?
Not that this is a big issue for my specific case. As you mentioned, for my case I can just delete the "tup init" from bootstrap.sh.
There are two options I would suggest trying - I don't know what other
issues you might encounter with them:
1) Keep tup as-is, and move the top of your project down one level (so
you'd have tup_src/.tup, and my_src/.tup)
I also thought of that.. but I'd rather avoid it, if possible.. not for any specific technical reason, it's just because I'd like to be able to run 'tup upd' in the root directory of my project :-)
2) Change tup's bootstrap.sh so it doesn't run ./build/tup init and
./build/tup/upd. You would just end up with the bootstrapped tup in
tup_src/build, and you should be able to have a single .tup directory
under $myprog.
Ok, I'd like to go with this option for now, if possible.
I'd like to know what you end up doing. Also, did you encounter any
specific issues with the Tupfiles under tup_src including the
Tuprules.tup file from your main project?
Yes, I think so. For example, I use a different !cc macro and different CFLAGS.
It seems I'm still running into the same issue, even with just one tup database:
$ tup upd
[ tup ] Scanning filesystem...0.006s
[ tup ] No tup.config changes.
[ tup ] Parsing Tupfiles...
[ 1/19 ] tup_src
Error: Attempting to insert 'ldpreload.o' as a generated node when it already exists as a different type. You can do one of two things to fix this:
1) If this file is really supposed to be created from the command, delete the file from the filesystem and try again.
2) Change your rule in the Tupfile so you aren't trying to overwrite the file.
Line was: ': foreach *.c'
- [1330] tup_src/src/ldpreload
Error parsing Tupfile [740] line 6
Line was: ': src/ldpreload/*.o'
- [740] tup_src
However, now I can't get tup to build even if I chdir into tup_src first (I guess because there's no database there now, so it also includes the rules from my project).
Even though it doesn't support chdir(), the git describe would
> I just fixed this problem locally by changing "version=`git describe`" into
> a hardcoded value corresponding to the tup version that I imported into my
> program's repository: "version="v0.3-148-ge66f2dd"".
probably still fail (since git is just searching up the tree for a
.git directory). Are you using git for your project? If so, you can
make tup's git repository a submodule of your main git repository.
Indeed. I'm using git as well, so using a git submodule would likely work.
That said, after reading the submodule documentation, I made a deliberate decision to import the code into my repo and hardcode the version, rather than use a submodule.
I'd probably use a submodule if there was a way for a "git clone" of my repository to automatically clone the tup subrepo as well.. Perhaps someday I will switch to submodules if/when they support that.
In the mean time, importing the code and changing 1 or 2 lines of code works just fine for me :-)
Thanks,
Ricardo
Ricardo M. Correia
I'd like to know what you end up doing. Also, did you encounter anyspecific issues with the Tupfiles under tup_src including the
Tuprules.tup file from your main project?
Yes, I think so. For example, I use a different !cc macro and different CFLAGS.
It seems I'm still running into the same issue, even with just one tup database:
Oh, actually, I think this has nothing to do with conflicting variables.
I can reproduce the same issue even without any extra Tupfiles.
For example, you can try these steps to reproduce:
$ git clone git://gittup.org/tup.git
$ cd tup
$ ./bootstrap.sh
$ rm -rf .tup
$ tup init
$ tup upd
Result:
[ tup ] No tup.config changes.
[ tup ] Parsing Tupfiles...
Error: Attempting to insert 'ldpreload.o' as a generated node when it already exists as a different type. You can do one of two things to fix this:
1) If this file is really supposed to be created from the command, delete the file from the filesystem and try again.
2) Change your rule in the Tupfile so you aren't trying to overwrite the file.
Line was: ': foreach *.c'
- [626] src/ldpreload
Error parsing Tupfile [1] line 6
Line was: ': src/ldpreload/*.o'
- [1]
Thanks,
Ricardo
Mike Shal
> On Sun, Nov 14, 2010 at 20:19, Mike Shal <mar...@gmail.com> wrote:
>>
>> The Tupfiles/Tuprules.tup files are limited in such a way that it
>> should always be possible to compose a superproject using subprojects
>> that individually build with tup (though there may be issues with
>> conflicting variables, as you alluded to).
>
> If you make that design decision (which sounds interesting to me), then
> there needs to be a solution for the conflicting variables.
> It's entirely possible (and likely) that two completely separate projects
> use the same variable names (!cc macro, or CFLAGS variables, for instance).
As it currently is, the Tuprules.tup files are parsed in order of the
directory hierarchy, so the variables are assumed to go from more
generic to more specific. If you define a !cc macro at the top of your
project, it can be overridden by any sub-project. That doesn't
necessarily mean they conflict, though. Anything inside that
sub-project will use it's particular !cc macro, and anything outside
of it will use the default top-level macro. I'm not claiming it's
perfect, so if you come across any specific issues feel free to report
them.
>
>> However, tup assumes there is only one database for the whole project.
>> It is not able to compose multiple databases (that would probably be a
>> nightmare given tup's implementation).
>
> This may be a stupid idea, but what if tup would always try to go up the
> directory tree up until the root directory (/) trying to find a database, so
> that it always finds the topmost one, regardless if there are others
> in-between?
>
> Not that this is a big issue for my specific case. As you mentioned, for my
> case I can just delete the "tup init" from bootstrap.sh.
Sounds reasonable to me. Though the test harness would have to be
changed, because each test case creates its own database underneath
the one used to build tup itself. Might be more effort than it's
worth.
As you mention later, this is not because of re-using !cc and such.
Whenever you wipe out a database, you clear out all record that tup
ever did any work, so you need to start over from scratch with a fresh
checkout of your project. (Wiping the database is not a normal
use-case of tup). The particular error message you are hitting is in
place so you don't accidentally create a rule where you overwrite a
file you just spent a long time creating but haven't bothered to
check-in yet. Tup will only automatically delete files that it has
created and are no longer used.
>
>>
>> > I just fixed this problem locally by changing "version=`git describe`"
>> > into
>> > a hardcoded value corresponding to the tup version that I imported into
>> > my
>> > program's repository: "version="v0.3-148-ge66f2dd"".
>>
>> Even though it doesn't support chdir(), the git describe would
>> probably still fail (since git is just searching up the tree for a
>> .git directory). Are you using git for your project? If so, you can
>> make tup's git repository a submodule of your main git repository.
>
> Indeed. I'm using git as well, so using a git submodule would likely work.
> That said, after reading the submodule documentation, I made a deliberate
> decision to import the code into my repo and hardcode the version, rather
> than use a submodule.
>
> I'd probably use a submodule if there was a way for a "git clone" of my
> repository to automatically clone the tup subrepo as well.. Perhaps someday
> I will switch to submodules if/when they support that.
You mean you just want 'git clone' to do everything, instead of 'git
clone && git submodule init && git submodule update' or whatever it
is? The submodule will be tied to a specific version in git, so your
users won't be somehow pulling in later versions of tup than what you
have tested with (unless they do so intentionally).
-Mike
Ricardo M. Correia
> On Sun, Nov 14, 2010 at 2:44 PM, Ricardo M. Correia <rcor...@wizy.org> wrote:
> > On Sun, Nov 14, 2010 at 20:19, Mike Shal <mar...@gmail.com> wrote:
> >>
> >> The Tupfiles/Tuprules.tup files are limited in such a way that it
> >> should always be possible to compose a superproject using subprojects
> >> that individually build with tup (though there may be issues with
> >> conflicting variables, as you alluded to).
> >
> > If you make that design decision (which sounds interesting to me), then
> > there needs to be a solution for the conflicting variables.
> > It's entirely possible (and likely) that two completely separate projects
> > use the same variable names (!cc macro, or CFLAGS variables, for instance).
>
> As it currently is, the Tuprules.tup files are parsed in order of the
> directory hierarchy, so the variables are assumed to go from more
> generic to more specific. If you define a !cc macro at the top of your
> project, it can be overridden by any sub-project. That doesn't
> necessarily mean they conflict, though. Anything inside that
> sub-project will use it's particular !cc macro, and anything outside
> of it will use the default top-level macro.
Cool.. if defining a macro in a directory replaces the same macro that
was defined in an upper directory, then that should work pretty well.
The only potential problem that I see in this particular case would be
when the sub-project uses a macro that he didn't define, but the
super-project did (e.g. someone makes a typo, and instead of writing "!
gcc" he writes "!cc" instead).
If they were separate projects, it would perhaps lead to an undefined
macro error, I guess? But with both projects combined, it wouldn't lead
to such an error (but could lead to other errors if e.g. the "!cc" in
the super-project is not equivalent to "!gcc" in the sub-project that
the user intended to use).
Personally, I don't think this is a big problem, though... you can
always make sure that the sub-project works by itself, by for example,
moving its directory to /tmp and compiling there.
> I'm not claiming it's
> perfect, so if you come across any specific issues feel free to report
> them.
There's one issue that I potentially see in my particular case: for
example, tup's own "Tuprules.tup" starts defining CFLAGS with this line:
CFLAGS += -Os
The way I understand it, this means that it won't override my
super-project's CFLAGS, but instead it will just append tup's CFLAGS to
my project's CFLAGS.
This means that my super-project is influencing the sub-project's flags,
which may be a problem depending on the flags that I decide to use for
my project.
That said, I'm not running into any issue because of this (in fact, I'm
circumventing this problem, more below), it's just an observation that
I'm making.
> As you mention later, this is not because of re-using !cc and such.
> Whenever you wipe out a database, you clear out all record that tup
> ever did any work, so you need to start over from scratch with a fresh
> checkout of your project. (Wiping the database is not a normal
> use-case of tup). The particular error message you are hitting is in
> place so you don't accidentally create a rule where you overwrite a
> file you just spent a long time creating but haven't bothered to
> check-in yet. Tup will only automatically delete files that it has
> created and are no longer used.
Interesting... I'm still trying to get used to tup's philosophy of not
allowing to clean build products.. maybe this is just a mental barrier
that we'll all overcome someday :-)
The other mental barrier I have is not being able to do partial builds,
i.e. telling tup to build only one thing, rather than everything.
This means that things like "make dist" can't be done with tup, but need
to be done in a separate script instead. Otherwise, tup would always
build a tarball of the project whenever I changed a single line of
code.. :-)
> > I'd probably use a submodule if there was a way for a "git clone" of my
> > repository to automatically clone the tup subrepo as well.. Perhaps someday
> > I will switch to submodules if/when they support that.
>
> You mean you just want 'git clone' to do everything, instead of 'git
> clone && git submodule init && git submodule update' or whatever it
> is?
Exactly.
> The submodule will be tied to a specific version in git, so your
> users won't be somehow pulling in later versions of tup than what you
> have tested with (unless they do so intentionally).
Right. I'm just importing the code into my repo to simplify things for
potential users, not that there's anything technically wrong with
submodules.
Thanks,
Ricardo
Jed Brown
The other mental barrier I have is not being able to do partial builds,
i.e. telling tup to build only one thing, rather than everything.
Mike Shal
I think Ricardo's case of building or not building a tarball can be
adequately handled with a tup.config variable. For example, by default
tup's own Tupfiles do not build the web pages, but can be enabled by
creating tup.config and setting CONFIG_TUP_WWW=y. You could make up a
similar variable, like CONFIG_MYPROJ_TARBALL, and only create the rule
to make the tarball if that variable is set.
Jed, for your case, I don't think config variables would help much.
There isn't any technical reason why tup can't support a partial
update, it just hasn't been done yet. It would just need to build the
partial DAG as it does now, and then I guess prune it to contain only
the paths that have the desired targets. Trying to work out the
details...
-Mike
Mike Shal
Ok, this turned out to be a bit easier than I expected (at least,
after staring at a DAG for an hour). The latest has support for
partial updates. They aren't documented, but should behave as you'd
expect (ie: 'tup upd foo.o bar.o' will only build what is necessary to
get those two objects). If the file you request wasn't going to be
built anyway, it will tell you that. Also the number of commands that
were skipped gets displayed at the end (assuming the part you
requested built successfully). Let me know if you come across any
issues with it.
-Mike
Jed Brown
> Ok, this turned out to be a bit easier than I expected (at least,
> after staring at a DAG for an hour). The latest has support for
> partial updates. They aren't documented, but should behave as you'd
> expect (ie: 'tup upd foo.o bar.o' will only build what is necessary to
> get those two objects). If the file you request wasn't going to be
> built anyway, it will tell you that. Also the number of commands that
> were skipped gets displayed at the end (assuming the part you
> requested built successfully). Let me know if you come across any
> issues with it.
Thanks, this works for me and makes Tup a much more useful tool.
I think the last particularly notable limitation relative to other
systems is a way to handle multiple independent build directories,
sometimes called "variant builds". The issue is that I may want to
build a debug and optimized version, or two versions compiled using
different compilers or different implementations of dependent libraries,
or just with different configuration options. Tup currently insists
that targets be produced in the source tree which pretty much means that
you can only have one build at a time.
Jed
Mike Shal
> I think the last particularly notable limitation relative to other
> systems is a way to handle multiple independent build directories,
> sometimes called "variant builds". The issue is that I may want to
> build a debug and optimized version, or two versions compiled using
> different compilers or different implementations of dependent libraries,
> or just with different configuration options. Tup currently insists
> that targets be produced in the source tree which pretty much means that
> you can only have one build at a time.
>
> Jed
>
Hi Jed,
I've been trying to think of a good way to do variants for a while,
but haven't actually tried implementing it yet. Based on the way tup
is currently, I think it would take the form of separate @-variable
namespaces, which would then get built into separate subdirectories
(the default would use tup.config and build in the source tree as
now). So if you wanted an in-source optimized build, and a debug build
in a separate tree, you might have:
tup.config:
CONFIG_MY_PROJ_CFLAGS="-O2"
debug.config:
CONFIG_MY_PROJ_CFLAGS="-g"
There might need to be some file describing where the variants should go, like:
tup.variants:
default=tup.config
debug=debug.config
I don't know how that would play out in practice though. Maybe I'll
give it a whirl when I have some spare time. What are your thoughts on
it?
-Mike
Jed Brown
Hi Jed,
I've been trying to think of a good way to do variants for a while,
but haven't actually tried implementing it yet. Based on the way tup
is currently, I think it would take the form of separate @-variable
namespaces, which would then get built into separate subdirectories
(the default would use tup.config and build in the source tree as
now). So if you wanted an in-source optimized build, and a debug build
in a separate tree, you might have:
tup.config:
CONFIG_MY_PROJ_CFLAGS="-O2"
debug.config:
CONFIG_MY_PROJ_CFLAGS="-g"
There might need to be some file describing where the variants should go, like:
tup.variants:
default=tup.config
debug=debug.config
I don't know how that would play out in practice though. Maybe I'll
give it a whirl when I have some spare time. What are your thoughts on
it?
Mike Shal
> On Tue, Nov 30, 2010 at 00:05, Mike Shal <mar...@gmail.com> wrote:
>>
>> Hi Jed,
>>
>> I've been trying to think of a good way to do variants for a while,
>> but haven't actually tried implementing it yet. Based on the way tup
>> is currently, I think it would take the form of separate @-variable
>> namespaces, which would then get built into separate subdirectories
>> (the default would use tup.config and build in the source tree as
>> now). So if you wanted an in-source optimized build, and a debug build
>> in a separate tree, you might have:
>>
>> tup.config:
>> CONFIG_MY_PROJ_CFLAGS="-O2"
>>
>> debug.config:
>> CONFIG_MY_PROJ_CFLAGS="-g"
>>
>> There might need to be some file describing where the variants should go,
>> like:
>>
>> tup.variants:
>> default=tup.config
>> debug=debug.config
>
> So does the user have to write these files and figure out how to update them
> when they want to build a variant that the developer did not prepare?
Not entirely sure what you mean here. The tup.config file format is
from kconfig, so while you could edit them directly, it'd probably be
nicer to use kconfig to write them. That way you can list out all of
the options for your project in a Kconfig file and provide help text
and such. But if the developer didn't have support in the Tupfiles for
supplying CFLAGS in tup.config, then an end-user wouldn't be able to
create a variant with different CFLAGS (unless they also modify the
Tupfiles).
I don't know if tup.variants would be necessary or not - maybe it
could just wildcard files with a certain extension instead.
>
>>
>> I don't know how that would play out in practice though. Maybe I'll
>> give it a whirl when I have some spare time. What are your thoughts on
>> it?
>
> In the general case where compiler support and properties of dependencies
> need to be discovered (supported features, how to link, etc), I think that
> some configure process in unavoidable. This does not need to be autoconf,
> which I generally hate, but something is needed. The model I prefer is
> cd project
> mkdir build-foo && cd build-foo
> ../configure --lots-of-options --specific-to-this --variant # Writes a
> "config.h" and some variables for Tup.
> tup upd # all build output goes below the current directory
I think in tup this would end up being something like:
cd project
tup variant add build-foo MY_PROJ_CFLAGS=-blah
(or maybe this brings up a kconfig editor... in any case, a new
.config file and tup.variants file are created as necessary)
tup upd
(now files are created in build-foo with @(MY_PROJ_CFLAGS) set to -blah)
You could still rm -rf the directory and corresponding .config file,
or maybe a 'tup variant rm build-foo' would be a wrapper for that.
> This allows an arbitrary number of variants to coexist, with options as
> defined by the user, and leaves the source directory pristine which makes it
> easy to blast it away when you no longer need it (just just delete
> build-foo).
> Note that this inverts the control model your proposed above. Instead of
> having one top-level that needs to know about all possible variants, each
> build directory has a link back to the source directory. With one project
> that I work on, I have over twenty of these variant builds, 6-10 of which I
> use on any particular day, and I guarantee that they are sufficiently
> diverse that nobody would want to maintain a single file describing all of
> them.
> Jed
>
The top-level wouldn't need to know about all possible variants, just
whichever ones are active. In your project you might just have a
default variant, or maybe a few templates, but the end-user could
always create new ones.
What sort of variants are you using? Is it a combination of different
compiler flags and feature sets?
Thanks,
-Mike
Jed Brown
I think in tup this would end up being something like:
cd project
tup variant add build-foo MY_PROJ_CFLAGS=-blah
(or maybe this brings up a kconfig editor... in any case, a new
.config file and tup.variants file are created as necessary)
tup upd
(now files are created in build-foo with @(MY_PROJ_CFLAGS) set to -blah)
You could still rm -rf the directory and corresponding .config file,
or maybe a 'tup variant rm build-foo' would be a wrapper for that.
The top-level wouldn't need to know about all possible variants, just
whichever ones are active. In your project you might just have a
default variant, or maybe a few templates, but the end-user could
always create new ones.
What sort of variants are you using? Is it a combination of different
compiler flags and feature sets?
Mike Shal
> On Wed, Dec 1, 2010 at 06:55, Mike Shal <mar...@gmail.com> wrote:
>>
>> I think in tup this would end up being something like:
>> cd project
>> tup variant add build-foo MY_PROJ_CFLAGS=-blah
>> (or maybe this brings up a kconfig editor... in any case, a new
>> .config file and tup.variants file are created as necessary)
>> tup upd
>> (now files are created in build-foo with @(MY_PROJ_CFLAGS) set to -blah)
>
> Okay, this sounds reasonable. It has the advantage that tup explicitly
> knows about all the variants so, in principle, it could share object files
> between them (if some files in two variants were built identically, though
> this is unlikely because config.h is almost guaranteed to be different).
> More commonly, it allows updating a bunch of variant builds with a constant
> number of threads (which are usually unevenly distributed between variant
> builds if you run
> parallel -P4 make -j4 -C ::: build-*
At least initially I wouldn't try to support sharing files between
variants due to the added complexity (tup doesn't have any knowledge
to do that sort of thing at the moment). The primary benefit to having
them inside one tup database would be the parallel updates.
>
>>
>> You could still rm -rf the directory and corresponding .config file,
>> or maybe a 'tup variant rm build-foo' would be a wrapper for that.
>
> Could tup garbage collect the .config when the build directory is deleted?
> Or even put the .config into the build directory? The reason I ask is
> because we already have some complexity through git rm and such, I would be
> cautious about adding additional special commands to remove something.
That's a good idea. Putting the file in the build directory sounds
like the right approach to me.
Thanks for the feedback!
-Mike