On Fri, Jan 10, 2014 at 1:33 AM, Elliott Conant <[email protected]>wrote:
> Hi Mike, thanks for the reply! > > That's a nice solution, it's a bit cleaner than what I came up with and I > might end up using it. The solution I came up with is to copy the internals > of the !cc macro and have it compile the files without specifying them as > inputs. I think it should still pick up changes outside the project with > updater.full_deps set. > > : |> @(CC) $(CFLAGS) /usr/src/gtest/src/gtest-all.cc \ > -I /usr/src/gtest -o gtest-all.o |> gtest-all.o > : |> @(CC) $(CFLAGS) /usr/src/gtest/src/gtest_main.cc \ > -I /usr/src/gtest -o gtest_main.o |> gtest_main.o > That was going to be my next suggestion :). You could still use a macro with this, but since you can't use %f or foreach it's a little wonky: !cc = |> gcc -c -o %o |> : |> !cc /path/to/foo.c |> foo.o : |> !cc /path/to/bar.c |> bar.o But if you're happy with the symlink, that's probably easiest for now. I think tup could be expanded to allow inputs in the parser that are external to tup, though I'm not sure how involved it would be. > > I think the most general and desirable solution to something like this > would be to invoke the foreign project's build system if it has one. It > happens that gtest/gmock (installed from .deb packages) have cmake scripts > so I tried to hook up with those: > > # Generate a Makefile for gtest in this directory > : |> cmake /usr/src/gtest |> > > But tup isn't happy about all of the stuff that gets generated: > > tup error: Directory > '/home/elliott/projects/Project/build-gcc_dbg/CMakeFiles/2.8.12.1' was > created, but not subsequently removed. Only temporary directories can be > created by commands. > ... > > It's actually close to 10 files in various directories that get generated > by this command so I wouldn't want to list them as outputs; there's a good > chance they would change in the future. I wonder if this approach has any > more potential? Would tup be happy if the generated files went outside of > the local project? > Aside from having to list the outputs, the problem with this approach is that tup is going to consider everything read by the build system as an input. If any of those inputs change, it will re-run the build system. Note also that tup deletes the old output files before running a sub-process, so in this case it would delete all of the outputs created by cmake before re-running cmake. Essentially, touching any file in the cmake project would cause tup to rebuild the entire cmake project from scratch. If you want to combine things like this, it is probably easier to have a top-level build script that invokes tup in some projects and cmake in others. A more involved option would be to get cmake to produce Tupfiles, or find a way to use the Lua parser to read cmake files directly to produce tup rules on-the-fly. This would take a lot of work, but would be more generally useful (it's come up on this list and the cmake list in the past). -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/groups/opt_out.
