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
<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] <javascript:>
unsubscribe: [email protected] <javascript:>
options: http://groups.google.com/group/tup-users?hl=en
<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] <javascript:>.
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>.
