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 +0200From: Christof Ressi <info@christofressi.com>To: pd-dev@lists.iem.atSubject: Re: [PD-dev] PD-specific tips for compiling faster on WindowsMessage-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/binChristof