Well, I did a rough implementation in parallel with the one done by Mozilla.
If you are a bit adventurous, the Tup backend developed at Mozilla is
available in mozilla-central (mozilla's officila repo) and is working
quite well.
See the doc here
https://firefox-source-docs.mozilla.org/build/buildsystem/tup.html (not
sure how fresh it is, I am not much related to Mozilla's implementation)
Their setup is a bit unusual however, because they use Tup as a backend
to their custom, python, build system front-end.
If this is of any interest to you, may I shamelessly recommend my short
paper on the subject ? It is available on CEUR here:
http://ceur-ws.org/Vol-2510/sattose2019_paper_2.pdf
-- Layus.
On 20/12/19 21:53, Gerardo Delgadillo wrote:
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] <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/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]
<mailto:[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>.
--
--
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/d0f67ed5-8113-ebbd-50ac-17103c183277%40gmail.com.
