Nice. We did something similar but with Chromium. Your paper is super interesting. Thanks for sharing it!
On Friday, December 20, 2019 at 3:02:17 PM UTC-6, Layus wrote: > > 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] >> 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] <javascript:> > unsubscribe: [email protected] <javascript:> > 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] <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> > . > > > -- -- 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/eed2ee10-2cb2-4193-a391-7260f0a8558d%40googlegroups.com.
