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.
On Apr 21, 2020, at 12:00 PM, pd-dev-request@lists.iem.at wrote:
Date: Tue, 21 Apr 2020 10:24:54 +0200 From: Christof Ressi <info@christofressi.com mailto:info@christofressi.com> To: pd-dev@lists.iem.at mailto: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 mailto: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
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
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.
Actually, I would volunteer to setup a CMake build system for Pd. CMake is really nice because it supports so many tool chains out of the box, including Visual Studio solutions and Unix Makefiles for MinGW.
Of course, this is not high priority, so I might give it a shot in summer or so.
Christof
On 21.04.2020 16:50, Dan Wilcox wrote:
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.
On Apr 21, 2020, at 12:00 PM, pd-dev-request@lists.iem.at mailto:pd-dev-request@lists.iem.at wrote:
Date: Tue, 21 Apr 2020 10:24:54 +0200 From: Christof Ressi <info@christofressi.com mailto:info@christofressi.com> To:pd-dev@lists.iem.at mailto: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 mailto: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
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com
Thanks a lot for your help, guys.
To be honest i was running make app (msw-app.sh, actually) everytime haha
As a newcomer its been hard wrapping my head around everything, especially since i'm used to interpreted languages - and Java, which is, well, Java.
(Christof, those C++17 conference videos you've sent me still gives me the nightmares)
So definitely i would say a better detailed dev guide would be great heh 🙂 We even discussed this brieflyhttps://lists.puredata.info/pipermail/pd-list/2019-10/126180.html in the list.
If i had the knowledge i would definitely help writing it - but i can help reviewing/testing.
Anyway thanks again for your tips. They will save me lots of time!
Cheers, Henri.
________________________________ De: Dan Wilcox danomatika@gmail.com Enviado: terça-feira, 21 de abril de 2020 11:50 Para: Christof Ressi info@christofressi.com; Henri Augusto Bisognini msndohenri@hotmail.com Cc: pd-dev pd-dev@lists.iem.at Assunto: Re: [PD-dev] PD-specific tips for compiling faster on Windows
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.
On Apr 21, 2020, at 12:00 PM, pd-dev-request@lists.iem.atmailto:pd-dev-request@lists.iem.at wrote:
Date: Tue, 21 Apr 2020 10:24:54 +0200 From: Christof Ressi <info@christofressi.commailto:info@christofressi.com> To: pd-dev@lists.iem.atmailto: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.commailto: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
-------- Dan Wilcox @danomatikahttp://twitter.com/danomatika danomatika.comhttp://danomatika.com robotcowboy.comhttp://robotcowboy.com
-
Christof Ressi -
Dan Wilcox -
Henri Augusto Bisognini