Hello, I ask here because I'm not sure about how to handle this problem, and would like to know of any better solution than the ones I've already thought about.
Imagine that you are working on a library. The sources are in src/. The library is a generated file, and its file name may change (its prefix would traditionally be "lib" on Linux systems, and its extension could be 'a', 'so', 'dll',…). So far, all is fine: : obj1.o obj2.o obj3.o |> !library |> $(LIBRARY_PREFIX)library.$( LIBRARY_EXTENSION) Now, imagine that, in the same project (.tup hierarchy), you include a test suite for your library. The tests reside in tests/. Each test unit command needs the library as input (typically to link to it). The only way to express cross-directory dependencies in Tup is to mention a file in another directory as input: : test1.o ../src/*WHAT**?* |> !program |> test1.exe The first solution that comes to mind is to use the same variables to construct the library's file name: : test1.o ../src/$(LIBRARY_PREFIX)library.$(LIBRARY_EXTENSION) |> !program |> test1.exe The problem now arises that the Tupfile in tests/ has to get access to the build parameters of the library (CC, CPPFLAGS, CFLAGS, LIBRARY_PREFIX, LIBRARY_EXTENSION, !object, !library,…). At first you could think that this is not a problem. In fact, you could ask: "Why wouldn't you use the same build parameters for the library and the test suite?". Well, for instance, one could want to build a dynamic library, in which case one would have to pass -fPIC for the library's objects, but not for the test units'. Then, one can think of debugging instrumentation, different optimization levels,… So, it's wrong to use LIBRARY_PREFIX and LIBRARY_EXTENSION (any of the library's build parameters, in fact) in any Tupfile other than the one corresponding to the library, in src/. Another solution one can think of is: "Always build a static version of the library (an archive) with debugging enabled to be used for the test suite". This seems ok, except that we wouldn't be testing the real library, and the test suite is also intended to check that enabling certain optimizations doesn't break anything. Finally, one could give up and use a fixed name for the library (say, library.lib). After all, installation is not one's problem; anyone wanting to install the library could just rename the file to their liking. The problem with this approach is that it is conceivable that some toolchains or systems require a particular naming scheme. BTW, this doesn't apply only to libraries, but also to object files (.o seems ubiquitous, but who knows…) and programs (no extension in Linux, .exe in Windows). Please, share any thoughts you have on this. I fear I might be locking myself in an XY-problem situation. -- -- 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/d/optout.
