Hi Sergio,
On Thu, Aug 30, 2012 at 3:00 PM, Sergio Garces <
sga...@gmail.com> wrote:
> Any update on the status of variants on Windows?
Sorry, I haven't had time to make progress here - people keep finding
other things that are broken :).
>
> What's the main problem to get this working?
You can see my last attempt if you clone from github in the
tmp-file-tree branch. The way variants work in Linux/OSX is as
follows: we have a source tree, which is the root of your project and
all sub-directories, and variant trees, which are any top-level
directories that have a tup.config file in them. We may have a Tupfile
like so:
src/Tupfile:
: |> gcc -c foo.c -o foo.o |> foo.o
In a normal build, tup would cd to src/, and then run that gcc
command. In a variant build, it will cd to build-foo/src, and then run
the gcc command. The fuse fs knows that when gcc tries to open foo.c,
it may be either in build-foo/src (if it was generated by another
rule), or in src (for all normal files). It is setup to transparently
allow gcc to do open("foo.c") and have it pull the file from the
source tree as necessary. Additionally, output files are temporarily
mapped to the .tup/tmp/ directory, so if several sub-processes all try
to open a "tmp.o" file (think old-school yacc and the like), they will
each get their own copy and won't conflict. After dependency checking,
tup moves the temporary files to their real location in build-foo/.
I was trying to duplicate this behavior in Windows, which on the
surface didn't seem too tricky since we already wrap all of the file
open & creation routines for dependency detection. However, I ran into
some trouble when sub-processes do (I think) the equivalent of stat()
on UNIX. The last commit in tmp-file-tree was where I tried to pull
out the remapping code from fuse so it could be shared with Windows,
but the NtQueryDirectoryFile function was causing problems. With the
remapping code in place I think it would be easier to add variants,
since the "if file is not in build tree, go to source tree" logic can
be handled in the mapping code, rather than in each hooked function.
>
> This is one of the main obstacles preventing us from adopting tup, and we'd
> be happy to help get it implemented if we can.
I could definitely use some help here, as Windows programming is not
my best. If you aren't sure where to start, let me know and I can give
it another try and maybe get a more detailed question for you (like
why does NtQueryDirectoryFile do X and not Y?). Also I do ask for a
signed contributor license agreement if you want to contribute code:
http://gittup.org/tup/icla.txt
Thanks,
-Mike