Hey IOhannes and all,
I'm wondering if now is a good time to continue with the MinGW porting. If not, I'll just remove Gem from the Windows nightly build. Any ideas on the -rpath being blank, IOhannes? I'm stumped, and I thought you might have some insight since you wrote most (all?) of the autotools stuff.
.hc
----------------------------------------------------------------------------
If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-08-22 20:33, Hans-Christoph Steiner wrote:
Hey IOhannes and all,
I'm wondering if now is a good time to continue with the MinGW porting. If not, I'll just remove Gem from the Windows nightly build. Any ideas on the -rpath being blank, IOhannes? I'm stumped, and I thought you might have some insight since you wrote most (all?) of the autotools stuff.
unfortunately i don't have any ideas right now how to fix it, and it (again :-() dropped in my priority list.
i still recommend doing a "make -k" for experimental(!) autobuilds, which would allow to leave non-working stuff in.
if you cannot live with that, it'd probably be best to remove it from the w32 builds for the time being.
fgamsdr IOhannes
On Wed, 24 Aug 2011 09:51 +0200, "IOhannes m zmoelnig" zmoelnig@iem.at wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-08-22 20:33, Hans-Christoph Steiner wrote:
Hey IOhannes and all,
I'm wondering if now is a good time to continue with the MinGW porting. If not, I'll just remove Gem from the Windows nightly build. Any ideas on the -rpath being blank, IOhannes? I'm stumped, and I thought you might have some insight since you wrote most (all?) of the autotools stuff.
unfortunately i don't have any ideas right now how to fix it, and it (again :-() dropped in my priority list.
i still recommend doing a "make -k" for experimental(!) autobuilds, which would allow to leave non-working stuff in.
if you cannot live with that, it'd probably be best to remove it from the w32 builds for the time being.
fgamsdr IOhannes
An essential part of the whole Pd-extended build process is making sure that all the pieces are there. Using make -k prevents that from working.
Anyway, I removed Gem from the Windows builds until we get it building under MinGW. Here's the commit: http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&revi...
.hc
-----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@.
fgmasdr IOhannes
On Thu, 25 Aug 2011 10:30 +0200, "IOhannes m zmoelnig" zmoelnig@iem.at 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
-
Hans-Christoph Steiner -
IOhannes m zmoelnig