Actually, 1-2 minutes is pretty good! Before Christof helped with improving the build on Windows, it was more into the 10 minute range due to the layout and compilation order of the files.
Christof is right in that if you are just testing smaller changes, you can just rebuild the core and put the compiled file into the bin folder to run it without having to rebuild the whole thing. I also do this on macOS where I build the Pd core
and simply copy the updated pd executable into the .app bundle without rebuilding the entire bundle each time.
Maybe we should include some dev / debug tips and tricks about this to the INSTALL.txt?
There has been interest for using CMake for libpd, so I could see that as a companion method to build Pd but not a replacement for autotools IMO. Then we would have 3 methods to build it, yeah! :P In any case, as long as something like this is
maintained, it's all good as Pd should be easy to compile on it's platforms.
Date:
Tue, 21 Apr 2020 10:24:54 +0200
From:
Christof Ressi <info@christofressi.com>
To: pd-dev@lists.iem.at
Subject:
Re: [PD-dev] PD-specific tips for compiling faster on Windows
Message-ID:
<4426262d-2274-567a-8e3c-fd2935e750fe@christofressi.com>
Content-Type:
text/plain; charset="windows-1252"; Format="flowed"
Autotools
(especially libtool) is very slow on MinGW. On my system,
compiling
the /extra externals takes significantly longer than compiling
the
actual Pd application, only because of libtool.
If
you want to get faster build times, rewrite the build system in CMake
and
compile with MSVC :-)
How
often do you need to recompile whole Pd? Usually, you just change
1-2
files and this should compile and link rather quickly. "make app" is
also
slow (again, because of libtool). Usually, I only run "make app"
once
and then just copy pd.dll into the Pd folder on the command line
(assuming
you only make changes to the core):
cp
./src/pd.dll ./pd-0.50.2/bin
Christof