For our projects, we use a slightly modified version of Chromium, and we build it with the tool they use: Ninja. So no porting its build to another system. Sorry for the confusion.
On Friday, December 20, 2019 at 3:20:50 PM UTC-6, Layus wrote: > > Thanks ! > > Something similar with chromium ? Do you by any chance have some > references to share about it ? > > -- Layus. > > On 20/12/19 22:07, Gerardo Delgadillo wrote: > > 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] >> 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> >> . >> >> >> -- > -- > 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/eed2ee10-2cb2-4193-a391-7260f0a8558d%40googlegroups.com > > <https://groups.google.com/d/msgid/tup-users/eed2ee10-2cb2-4193-a391-7260f0a8558d%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/7004e3e7-c620-4359-86ef-751ee650e32b%40googlegroups.com.
