To Pd developers -
I'm finally gearing up to clean out the "old build system" which, I believe, will entail removing these files from pd/src:
config.h.in configure configure.in install-sh makefile.clean makefile.dependencies makefile.in
... any objections? (i.e. is anyone but me still using this who can't move forward to the "new' system (cd pd; autogen.sh; ./configure; make) ?
I'm planning on leaving makefile.nt and makefile.mingw around for luddites, and also will probably supply a makefile.gnu as a fallback for when, I predict inevitably, the "new build system" crumbles under its own weight.
cheers Miller
Yes, this sounds great! On the topic of the new build system, its quite close to working on MinGW. The new build system will never work for MSVC, so it makes sense to keep the makefile.nt, but I think it should renamed Makefile.msvc to make it clear what its for.
Also, in Pd-extended, I've removed some stuff from configure.ac to simplify it. There are a number of tests that we don't need there. I think the key to keeping the build system maintainable is to keep it as simple as possible. So including tests of things that have no automatic response is not useful for all but a couple people who know how to add them in anyhow.
Attached is my patch to remove those tests.
.hc
On Nov 18, 2012, at 2:42 PM, Miller Puckette wrote:
To Pd developers -
I'm finally gearing up to clean out the "old build system" which, I believe, will entail removing these files from pd/src:
config.h.in configure configure.in install-sh makefile.clean makefile.dependencies makefile.in
... any objections? (i.e. is anyone but me still using this who can't move forward to the "new' system (cd pd; autogen.sh; ./configure; make) ?
I'm planning on leaving makefile.nt and makefile.mingw around for luddites, and also will probably supply a makefile.gnu as a fallback for when, I predict inevitably, the "new build system" crumbles under its own weight.
cheers Miller
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On 11/19/2012 07:33 PM, Hans-Christoph Steiner wrote:
The new build system will never work for MSVC,
why? what keeps you from using autotools with msvc? (sure, autotools require mingw/cygwin to run the bash-script (and once you installed mingw/cygwin, installing gcc is easy enough), but whether your compiler is gcc or msvc shouldn't matter)
fgmasdr IOhannes
On Nov 19, 2012, at 5:20 PM, IOhannes m zmölnig wrote:
On 11/19/2012 07:33 PM, Hans-Christoph Steiner wrote:
The new build system will never work for MSVC,
why? what keeps you from using autotools with msvc? (sure, autotools require mingw/cygwin to run the bash-script (and once you installed mingw/cygwin, installing gcc is easy enough), but whether your compiler is gcc or msvc shouldn't matter)
I have no particular objection to someone doing it, it just seems like a recipe for a lot of pain with little good reason. Sounds like you have to do a lot of crazy kludges:
http://lists.gnu.org/archive/html/autoconf/2004-09/msg00061.html
in which case, I think it'll be much less work for everyone involved to maintain the MSVC builds in a separate file, just like the build systems for Rockbox, iOS, Android, etc. Basically no one is using the autotools build that is there for iOS and Android. I think we should remove the iOS and Android stuff from the autotools build and call libpd the official iOS and Android build system. That's already the de facto case.
.hc
On 11/20/2012 04:44 AM, Hans-Christoph Steiner wrote:
On Nov 19, 2012, at 5:20 PM, IOhannes m zmölnig wrote:
On 11/19/2012 07:33 PM, Hans-Christoph Steiner wrote:
The new build system will never work for MSVC,
why? what keeps you from using autotools with msvc?
I have no particular objection to someone doing it,
i was merely trying to point out that a statement like "the new build system will never work on MSVC" is not right.
fgmasdr IOhannes