'Tup clean' argument

[dirkson]

Hi there!

If the version of a compilation tool changes between tup compiles, the output of a compilation step can change in a way that a tup user might care about, but that tup can't currently account for.

As an example, the commonmark-to-html tool I was using to compile my website recently changed its default behavior from "copy html in commonmark files" to "remove html in commonmark files". I ended up need to emulate a "Tup clean" by manually removing most of the generated files, to force tup to regenerate everything using the new method.

This could be solved by introducing 'tup clean', or by having tup do some sort of hash on the binaries and/or command lines used for compilation. The second sounds both messy and difficult, and it may result in recompilation when the user doesn't want it - Most GCC version bumps can be safely ignored, for example. This leaves 'tup clean' as the cleanest obvious solution to this particular problem.

Please feel free to correct me if I've said something dumb, or if you can think up a solution I missed.

Cheers,

-Dirk

[Robb Matzke]

Hi,

I work on a large project that has 160 Tupfiles for 20k C++ source
files that needs to be tested for portability across more than 30
C++ compiler versions, 20 Boost versions, and many other
dependencies. My practice is to install each dependency in its own
version-specific installation prefix, and thus changing
dependencies causes tup to rebuild affected artifacts because the
compiler paths and/or switches change. I'm switching between
dependencies on a daily basis and have never missed tup's lack of
a "clean", although my setup is probably atypical.

--Robb

> --

[Emery Hemingway]

Hello,

I manage my tooling with the 'nix-shell' utility from Nix/Nixpkgs/NixOS.
As a result, my PATH environmental variable contains a unique path
element for each tool included in the managed enviroment, and when a
tool is updated Tup will detect a PATH change and rebuild everything
(expensive, but those who sacrifice correctness for convenience shall
have neither).

To ensure that I only build within the managed environment, I do not
install Tup globally, but make it available as part of my development
shell. This approach requires the Nix package manager to be installed,
but one does not need to be using the NixOS disto.

https://nixos.org/nix/manual/#sec-nix-shell
https://github.com/ehmry/genode-ehmry/blob/master/default.nix

Cheers,
Emery

On Wednesday, July 3, 2019 9:21:51 PM CEST, Robb Matzke wrote:
> Hi,
>
> I work on a large project that has 160 Tupfiles for 20k C++
> source files that needs to be tested for portability across more
> than 30 C++ compiler versions, 20 Boost versions, and many other
> dependencies. My practice is to install each dependency in its
> own version-specific installation prefix, and thus changing
> dependencies causes tup to rebuild affected artifacts because
> the compiler paths and/or switches change. I'm switching between
> dependencies on a daily basis and have never missed tup's lack
> of a "clean", although my setup is probably atypical.
>
> --Robb
>
>
>
> dirkson writes:
>
>> Hi there!
>>
>> If the version of a compilation tool changes between tup compiles, the
>> output of a compilation step can change in a way that a tup
>> user might care
>> about, but that tup can't currently account for.
>>

>> As an example, the commonmark-to-html tool I was using to compile my ...
>

[Guillaume Maudoux (Layus)]

Hi,

You could also have a look at updater.full_deps option (http://gittup.org/tup/manual.html#lbAH). It extends tracking of dependencies to the whole filesystem and is the only built-in answer for your problem.

Now, you should really try it to see if it suits you. It can have unforeseen effects. For example, it does not play well with NixOS because Tup catches changes in symlink chains pointing to the same tools.

Regards,

-- Guillaume.

--
--
tup-users mailing list
email: tup-...@googlegroups.com
unsubscribe: tup-users+...@googlegroups.com
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 tup-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tup-users/9443b786-05b0-419e-be88-1a6eabdcae86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.