On Thu, 25 Aug 2011 10:30 +0200, "IOhannes m zmoelnig" <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2011-08-24 19:27, Hans-Christoph Steiner wrote: > > An essential part of the whole Pd-extended build process is making sure > > that all the pieces are there. > > sure. > > > Using make -k prevents that from > > working. > > i don't see how. > > using "make -k", the build will _still fail_ if one of the sub-targets > fail. > the main difference is, that before failing, it will eat a lot more > ressources, as it goes on compiling the rest of Pd-extended. > > personally, i "quite often" (at least that is my feeling :-)) look at > the build logs to see whether anything went wrong in parts that lie > within my responsibility. > if so, i try to fix these things asap. > > imagine trivial bugs in "Gem", "iemnet", "iemguts" and "zexy" that > produce an FTBFS on various non-linux platforms for all those. > even if manage to fix the Gem part after the 1st build, it will take at > least 3 more nights to get noticed of the other problems. > > if the builds are not for devs to fix their FTBFS bugs, then we could > probably turn off the automatic mailing of the build-logs to pd-cvs@.
This is an old issue that has been discussed many times over the years. What new information is there now that should change all the previous decisions? A better solution than breaking the current Pd-extended build system is to setup something like jenkins for people to run their own libraries directly, with builds depending on nothing else. .hc _______________________________________________ GEM-dev mailing list [email protected] http://lists.puredata.info/listinfo/gem-dev
