Hans-Christoph Steiner wrote:
I am getting conflicts just my using your build stuff. Could you remove zexyconf.h from CVS since its dynamically generated? Otherwise this will require manual intervention after automatic builds.
RCS file: /cvsroot/pure-data/externals/zexy/src/zexyconf.h,v retrieving revision 1.3 retrieving revision 1.4 Merging differences between 1.3 and 1.4 into zexyconf.h rcsmerge: warning: conflicts during merge cvs update: conflicts found in zexy/src/zexyconf.h C zexy/src/zexyconf.h
i see. this is indeed a problem. the reason why zexyconf.h is checked in, is that you can also build zexy with M$VC without running configure first: in this case nobody will create the zexyconf.h file, which - imho - makes building overcomplicated (i don't think it is an option to tell people to copy zexyconf.h.in to zexyconf.h and edit to their needs).
the issue here was, that incidentially a "generic" zexyconf.h has been overwritten in the past by a generated file. i have to read the CVS manual, to see how to exclude checked in files from being updated.
another solution might be, to run "make distclean" before doing CVS updates, which will remove the generated files.
mfgg.ar IOhannes
On Oct 19, 2006, at 4:43 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
I am getting conflicts just my using your build stuff. Could you remove zexyconf.h from CVS since its dynamically generated? Otherwise this will require manual intervention after automatic builds. RCS file: /cvsroot/pure-data/externals/zexy/src/zexyconf.h,v retrieving revision 1.3 retrieving revision 1.4 Merging differences between 1.3 and 1.4 into zexyconf.h rcsmerge: warning: conflicts during merge cvs update: conflicts found in zexy/src/zexyconf.h C zexy/src/zexyconf.h
i see. this is indeed a problem. the reason why zexyconf.h is checked in, is that you can also build zexy with M$VC without running configure first: in this case nobody will create the zexyconf.h file, which - imho - makes building overcomplicated (i don't think it is an option to tell people to copy zexyconf.h.in to zexyconf.h and edit to their needs).
That sounds good. I think its far too much work to support every compiler under the sun. I like gcc on all platforms.
the issue here was, that incidentially a "generic" zexyconf.h has been overwritten in the past by a generated file. i have to read the CVS manual, to see how to exclude checked in files from being updated.
another solution might be, to run "make distclean" before doing CVS updates, which will remove the generated files.
That would be a workaround, rather than a fix. Sounds likely to introduce more problems in the future.
.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
Hans-Christoph Steiner wrote:
On Oct 19, 2006, at 4:43 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
I am getting conflicts just my using your build stuff. Could you remove zexyconf.h from CVS since its dynamically generated? Otherwise this will require manual intervention after automatic builds. RCS file: /cvsroot/pure-data/externals/zexy/src/zexyconf.h,v retrieving revision 1.3 retrieving revision 1.4 Merging differences between 1.3 and 1.4 into zexyconf.h rcsmerge: warning: conflicts during merge cvs update: conflicts found in zexy/src/zexyconf.h C zexy/src/zexyconf.h
i see. this is indeed a problem. the reason why zexyconf.h is checked in, is that you can also build zexy with M$VC without running configure first: in this case nobody will create the zexyconf.h file, which - imho - makes building overcomplicated (i don't think it is an option to tell people to copy zexyconf.h.in to zexyconf.h and edit to their needs).
That sounds good. I think its far too much work to support every compiler under the sun. I like gcc on all platforms.
Yes black and white is easier than colour. But if MS has made the OS then MS 's compiler is likely to be the best for that platform. There are only three (3) platforms that anyone here has ever mentioned. gcc is really good on linux. Martin
On Oct 27, 2006, at 12:54 AM, Martin Peach wrote:
Hans-Christoph Steiner wrote:
On Oct 19, 2006, at 4:43 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
I am getting conflicts just my using your build stuff. Could you remove zexyconf.h from CVS since its dynamically generated? Otherwise this will require manual intervention after automatic builds. RCS file: /cvsroot/pure-data/externals/zexy/src/zexyconf.h,v retrieving revision 1.3 retrieving revision 1.4 Merging differences between 1.3 and 1.4 into zexyconf.h rcsmerge: warning: conflicts during merge cvs update: conflicts found in zexy/src/zexyconf.h C zexy/src/zexyconf.h
i see. this is indeed a problem. the reason why zexyconf.h is checked in, is that you can also build zexy with M$VC without running configure first: in this case nobody will create the zexyconf.h file, which - imho - makes building overcomplicated (i don't think it is an option to tell people to copy zexyconf.h.in to zexyconf.h and edit to their needs).
That sounds good. I think its far too much work to support every compiler under the sun. I like gcc on all platforms.
Yes black and white is easier than colour. But if MS has made the OS then MS 's compiler is likely to be the best for that platform. There are only three (3) platforms that anyone here has ever mentioned. gcc is really good on linux. Martin
Actually Apple uses gcc as its native compiler also, and they contribute a lot to gcc as well. I am not opposed to people using the Windows compilers. But most of the stuff in CVS does not compile with the Windows compilers. Basically everything compiles with gcc on Windows.
Its a lot of work to support the Microsoft compiler, and so far no one is really doing it, besides little bits here and there.
Also, since Pd is free software, it makes sense that it should be buildable with free software. Right now, Windows and ASIO are the the only non-free parts. A ReactOS build would fix that.
.hc
------------------------------------------------------------------------
I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler
hi hans ...
Also, since Pd is free software, it makes sense that it should be buildable with free software. Right now, Windows and ASIO are the the only non-free parts.
is coreaudio free?
A ReactOS build would fix that.
concerning the wikipedia page of reactos (their website is currently down), it's still considered as an alpha software. have you ever tried it?
cheers .... tim
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
Silence is only frightening to people who are compulsively verbalizing. William S. Burroughs
On Oct 27, 2006, at 4:26 AM, Tim Blechmann wrote:
hi hans ...
Also, since Pd is free software, it makes sense that it should be buildable with free software. Right now, Windows and ASIO are the the only non-free parts.
is coreaudio free?
I meant on Windows. CoreAudio is not free, but its part of the OS. Windows MME is also not free, but its part of the OS. Either is much easier to manage than ASIO since they are part of the OS.
A ReactOS build would fix that.
concerning the wikipedia page of reactos (their website is currently down), it's still considered as an alpha software. have you ever tried it?
Yes, its alpha software, but I think it should be on our radar, or at least those of us who care about free software. I'll be setting up a ReactOS box for the build farm soon.
.hc
------------------------------------------------------------------------
News is what people want to keep hidden and everything else is publicity. - Bill Moyers