Hi Ervin,

I only have an answer to your first question: no, I don't think this is
a bug in tup. From http://gittup.org/tup/manual.html

   Note that you may see a syntax using back-ticks when setting
   variables, such as:

   CFLAGS += `pkg-config fuse --cflags`

   *_Tup does not do any special processing for back-ticks_*, so the
   pkg-config command is not actually executed when the variable is set
   in this example. Instead, this is passed verbatim to any place that
   uses it. Therefore if a command later references $(CFLAGS), it will
   contain the string `pkg-config fuse --cflags`, so it will be parsed
   by the shell.

I have emphasised the important part for you. This behaviour is
different from make! Unfortunately I don't have an idea how to solve
your problem. May be the Lua scripting feature of tup is of help?

Kind regards, Bernhard.

On 15.06.2019 14:30, Ervin Oro wrote:
Let's say that I want all inc* directories in project to be
automatically in the include path. In my Makefile I used to have the
following:

|
CFLAGS =$(shell find "$(CURDIR)"-iname inc*-execfind {}-type d \;|sed
-e "s/^/-I/")
|

I am not at all sure, how to do that with tup, but I came up with the
following solution:

|
CFLAGS ='\\$(find "'..tup.getcwd()..'" -iname inc* -exec find {} -type
d \\; | sed -e "s/^/-I/")'
|

CFLAGS then gets included in the compilation command. I would assume
that tup then instruments the find executable, and notices that it
reads the content of all directories, therefore detecting all
directories as dependencies? This does not seem to be the case
however: adding new directories (named inc) does not cause
re-compilation of sources.

When I add a new directory named inc, such that it appears first in
the find output, and create a new .h file there, named such that it
would be included in some existing source, tup claims that everything
is up to date (while the output actually doesn't include the new
header), but does compile with this new header after I manually delete
previous output files.

As the manual claims that "Should you find otherwise, you've likely
found a bug in tup (not your Tupfiles), in which case you should
notify the mailing list.", so here I am. Two questions: is this a bug,
and how to best achieve my desired result with tup? Note that the
solution that I came up with executes the find commands again for each
compiled source, which is not really optimal, how could I have it so
that it gets called at most once per tup update? (My previous make
solution of course required make clean, but then again, it had support
for make clean.)

--
--
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].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tup-users/8e1af46f-5959-f6cb-f53d-9d05bd7126d3%40gmx.eu.
For more options, visit https://groups.google.com/d/optout.

Reply via email to