Hi,

I have a tup file that looks like this:

include_rules

PRJ_DIR = ..

LDFLAGS += -lpthread

: $(PRJ_DIR)/lib/googletest/gtest.a $(PRJ_DIR)/lib/googlemock/gmock.a 
$(PRJ_DIR)/source/source.a $(PRJ_DIR)/test/test.a |> g++ -o %o 
$(PRJ_DIR)/lib/googletest/gtest.a *-Wl,--whole-archive* 
$(PRJ_DIR)/test/test.a *-Wl,--no-whole-archive* $(PRJ_DIR)/source/source.a 
$(PRJ_DIR)/lib/googlemock/gmock.a $(LDFLAGS) |> test


and a Tuprules.tup file that looks like this (have removed parts not 
relevant to this post):


LDFLAGS          = 

!link_binary = |> g++ -o %o %f $(LDFLAGS) |>

*My real question is *-- I'm keen to use the !-macro link_binary in my 
Tupfile but because of the -Wl,--whole-archive and -Wl,--no-whole-archive I 
don't see a way in which this is possible. Note that the position of these 
arguments is important. Could someone put me out of my misery and tell me 
whether there's a cleaner way of writing my tup file (ideally I like to 
abstract away from the actual link command as much as possible in the 
Tupfile and put that logic in Tuprules.tup). Ideally using !-macros.

*My comments on tup (should anyone care) *-- Apologies if the rest of this 
post sounds like a rant -- it isn't. I really like tup and it has got some 
really nice things going for it. I particularly like it's clean syntax, 
it's ability to monitor file dependencies and tell me off when I missed a 
particular dependency, and it's ability to write my .gitignore files. I 
don't particularly care about how quick it is -- make is also quick enough. 
There's a few things lacking in tup that -- if fixed -- would make Tup a 
real killer build system:

   - Not having a "clean" command. I understand the reason why this was 
   omitted but I think that reason is misinformed. There are legitimate 
   reasons why you might want a proper clean command (like seeing warnings 
   again or re-building everything because you've updated your version of 
   g++). It's not accurate to say you can do this with "git clean -xf" because 
   there's a world outside of tup. Not every single non-versioned file I have 
   in my git checkout is generated by tup and git has no way to discriminate 
   between files generated through tup and files I created myself outside of 
   tup and don't want to lose. Maybe you've been editing source files and 
   aren't at a good place to commit them yet but you do want a clean build 
   because you want to get rid of this one warning. Doing a git clean would 
   delete your uncommitted source files (I've done this!). In short: there is 
   a use case for wanting to delete all the files generated by tup and only 
   tup knows what those files are. You are limiting the usefulness of tup by 
   omitting a clean command.
   - Not being able to write output files outside of the current directory. 
   This is more than just an annoyance as it prevents me from, say, doing a 
   wget of a zip file on the web, unzipping it in a directory and then 
   building the source in that directory. It might sound far-fetched but I 
   really don't think it is.
   - Not being able to real environmental variables (like the system's CXX 
   variable, say). When I'm cross-compiling stuff these variables is where 
   it's at.
   - I would really like it if tup made it easier to inject dependencies. 
   When I'm building a library Foo that depends on Bar really in Foo's Tupfile 
   all I want to say is that it depends on Bar; I don't want to say what 
   compiler switches I need in Foo because of that dependency -- ideally those 
   switches should be defined in Bar's Tupfile and pulled into Foo 
   automatically, but I don't see a way in which I can do that in tup.
   - Not supporting having multiple wild-cards in foreach specifications 
   (it's possible this is supported and it is a user error).

I'll stop now! Please note that I am picking on a few points that tup 
doesn't do so well only because I think it does a lot of other things 
better than tools like GNU Make and there's a lot of potentialy here! Keep 
up the good work.

Kind regards,

Mark


-- 
-- 
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.

Reply via email to