W dniu 2014-07-26 04:48, Mike Shal pisze:
On Sun, Jun 22, 2014 at 5:34 AM, Freddie Chopin
<[email protected] <mailto:[email protected]>> wrote:
Hello!
I guess the main reason to ignore hidden (dot) files and directories
is to ignore .tup folder with the database. But is there a good
reason to ignore ALL such files/directories? Recently there was a
discussion about a simple operation of generating repository hash
which is not possible with tup because this would depend on a file
in .git folder...
If the only reason is to ignore .tup then maybe it would be possible
to change tup to ignore this folder only, not all starting with dot?
On the other hand - is it really necessary to ignore .tup folder
(assuming that's the reason for this rule)?
Primarily it was to ignore both .tup and .git - I don't think there's
any reason for a sub-process to be using files in .tup, so there's no we
don't need to scan & track them.
Agree - there's nothing in the .tup you should depend on.
In .git, I think (maybe incorrectly?)
that things would be changing as things get put into packs, or stashed,
or whatever, that it would cause a lot of spurious rebuilds if you had
sub-processes depend on those files.
Possibly true, but you would heave exactly what you wanted - if you
depend on files that are changing so frequently, expect frequent
rebuilds. I see nothing wrong in that (;
Maybe you can try to disable the
ignore-the-dot-folders feature and see if it helps or just makes things
annoying :)
Any pointers on where should I disable that? Is it hard to cross-compile
tup for Windows? If it is (and if that wouldn't be a big problem), would
it be possible for you to compile such version for Windows and post
somewhere?
Anyway - a feature "tup ignore" could be related. For example on default
tup would ignore just the minimum, so only .tup. But with a new command
"ignore" you could designate some other folders to be inaccessible - for
example you could ignore .git if that bothers you. When the folder would
be ignored it wouldn't be possible to read from it or write to it. I
guess this could also apply to individual files, but that is probably
not so useful. I guess this command could be placed in Tupfile.ini of
the project, as there's no point in having it all over tupfiles.
Does it make any sense? I guess the ability to generate the hash from
the repo (or a date of source or things like that) is pretty nice, but
currently not possible to do in plain tup.
Regards,
FCh
--
--
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.
