Porting Firefox's build to tup! That sounds like lots
and lots of libraries and files, etc. Wow! I'm
impressed. At my company, we "only" have 130 Eclipse
projects to port. Other projects I'm not considering
because they aren't Eclipse projects, use make, ninja,
and gradle. Joy, right?
On Friday, December 20, 2019 at 2:47:09 PM UTC-6, Layus
wrote:
I asked myself the same question during the process
of porting Firefox's build to Tup.
The bottom line seems that of course, you can get a
perfectly correct build system with make, *if* you
are willing to think about all the corer cases yourself.
Tup alleviates much of the mental load, and relieves
yourself from working around each of make limitations.
Of course, using .d files can work around dependency
detection, but you need to wire that in make, making
it more complex, and any mistake in the way you
implement it leads to potential incorrect builds.
Of course, you can take special care to filter
environment variables, and force make to rebuild
when they change (well, I have no idea how, but
writing their content to a file that is a dependency
to all the targets may be a start).
Of course, you can force make to rebuild when the
makefile itself changed, but again you have to
clutter your makefiles to do that, and get an
half-backed solution.
Why would you do that by hand (and maintain that by
hand) when you can get it baked-in in your tool.
Just have a look at the kind of makefiles that cmake
generates. They handle most of the above, and are
clearly unmaintainable manually.
That would be my not too theoretical argument.
Oh, and tup comes with a monitor, that tracks
changes and rebuilds immediately :-).
Also, all of the above work-arounds have
shortcomings that I find extremely important to
consider, but are less convincing to random end-users.
1/ GNU -MD does not handle missing files. This means
that adding a new header earlier in the includes
search path will not be detected. Tup does that.
(and can do that for system headers if asked to).
2/ Depending on Makefiles themselves is a common
trick, but it is coarse grained, as all the targets
in a Makefile would need to be rebuilt whenever one
changes (This is more about speed, that you
specifically asked not to consider).
3/ Make will not tell you when you have hidden
(a.k.a. undeclared) dependencies. So you may achieve
a correct build definition with Make, but you will
never be certain you do. Why live with uncertainty
when it can be ruled out ?
Now, Tup comes with some constraints due to all the
correctness enforcement. These would be valid
reasons not to use it if you build is so peculiar
that it its them.
Time to stop, but I have tons of arguments in stock :-).
-- Layus.
On 20/12/19 01:07, Gerardo Delgadillo wrote:
I'm porting Eclipse C++ project builds (ugly) to
something more reliable. My C++ projects consist of
many-many libraries and executable files. So, as a
test, I ported a few to to TUP, and it works great.
However, a co-worker asked, "Why not just use make
instead? It's in all the servers and works great."
My reply was: "Auto-dependency detection and
speed." Now, speed is very nice but it isn't much
of an issue in our case. Then, he said that given
the right inputs (.cpp, .h, .d files. etc.), make
can deal with dependencies if used along with GNU
-MD flag to generate the 'd' files, etc.
What's your take on this never-ending debate? (I.e.
I couldn't convince him of tup's superiority).
--
--
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/7060f6d5-b72b-4389-99e9-ca945c2a7b11%40googlegroups.com
<https://groups.google.com/d/msgid/tup-users/7060f6d5-b72b-4389-99e9-ca945c2a7b11%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
--
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/4e5f210a-5608-4339-9152-ae6d2bcd5f67%40googlegroups.com
<https://groups.google.com/d/msgid/tup-users/4e5f210a-5608-4339-9152-ae6d2bcd5f67%40googlegroups.com?utm_medium=email&utm_source=footer>.
