Hey all
The new deken plugin makes me want to compile externals for Windows. There seem to be many ways to go and I might save some time if I knew beforehand what works and what no so well. I have access to the following archs:
* Debian 7 (i386, amd64, armv6l) * Debian 8 (i383, amd64) * Ubuntu 14.04 (i386, amd64) * Windows XP (w32)
What are people using? Are you compiling directly on Windows or are you cross-compiling from Linux? Are you going with the tool chain from your Distro or are you downloading the highest and latest manually?
On a related note: How feasible is it to cross-compile for Mac OS X?
Roman
Hi Roman,
Hey all
The new deken plugin makes me want to compile externals for Windows. There seem to be many ways to go and I might save some time if I knew beforehand what works and what no so well. I have access to the following archs:
- Debian 7 (i386, amd64, armv6l)
- Debian 8 (i383, amd64)
- Ubuntu 14.04 (i386, amd64)
- Windows XP (w32)
What are people using? Are you compiling directly on Windows or are you cross-compiling from Linux? Are you going with the tool chain from your Distro or are you downloading the highest and latest manually?
Everything I compiled is done native. Only for MacOSX, the build creates three executables into one fat binary. The code is straight from https://sourceforge.net/p/pure-data. Having a native platform, you can do some testing too.
Most external libraries have no external dependencies, and are easy to build everywhere. Even with dependencies, building isn't that complicated, even on the ancient MacOSX 10.5, where Fink & co. isn't very usable.
The build system I use is a replacement for the Library Template makefile that will be announced soon. During beta testing it could build about 60 of the current pd-external libraries without much effort and no code changes.
On a related note: How feasible is it to cross-compile for Mac OS X?
I choose the simple solution, by using an old Mac. The appropriate Xcode contains a gcc tuned for MacOSX and builds the three architectures out of the box.
Roman
Greetings,
Fred Jan
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
Hi,
On 21/06/15 18:13, Roman Haefeli wrote:
The new deken plugin makes me want to compile externals for Windows.
Any compiles and testing you can do with Deken on Windows is much appreciated, thank you so much.
What are people using? Are you compiling directly on Windows or are you cross-compiling from Linux? Are you going with the tool chain from your Distro or are you downloading the highest and latest manually?
So far in my limited experiments have been to upload existing externals from the last good build of the old Pd-extended binaries packages:
http://autobuild.puredata.info/auto-build/2013-08-08/
And then test them with Wine because my Windows XP virtualbox is doing the same thing you reported yours was doing in 2011 here:
http://lists.puredata.info/pipermail/pd-list/2011-11/092698.html
If you have a chance to try out the 'freeverb~' external I uploaded on a Pd-vanilla 0.46 from Miller and to let me know if that works for you on Windows that would be very useful. If it works I'll upload more of the old Pd-extended externals binaries.
Once we have a good set of externals live I guess it would make sense to tentatively let people on the Pd-list know about this method of obtaining externals.
Cheers,
Chris.
I compile externs both in mingw and in Microsoft Visual C running under wine (so both from linux). I keep a Windows XP machine around and crank it up to test things when I put out Pd releases, but all eh compiling happens in linux, and the first round of testing is under wine, which allows me to catch most problems without having to turn on Windows. (BTW my Windows machine is behind a firewall and has no name server configured in an attempt to keep whatever malware it's running from damaging anything. I recommend never putting a Windows machine where it can access the internet.)
cheers Miller
On Sun, Jun 21, 2015 at 08:17:03PM +0800, Chris McCormick wrote:
Hi,
On 21/06/15 18:13, Roman Haefeli wrote:
The new deken plugin makes me want to compile externals for Windows.
Any compiles and testing you can do with Deken on Windows is much appreciated, thank you so much.
What are people using? Are you compiling directly on Windows or are you cross-compiling from Linux? Are you going with the tool chain from your Distro or are you downloading the highest and latest manually?
So far in my limited experiments have been to upload existing externals from the last good build of the old Pd-extended binaries packages:
http://autobuild.puredata.info/auto-build/2013-08-08/
And then test them with Wine because my Windows XP virtualbox is doing the same thing you reported yours was doing in 2011 here:
http://lists.puredata.info/pipermail/pd-list/2011-11/092698.html
If you have a chance to try out the 'freeverb~' external I uploaded on a Pd-vanilla 0.46 from Miller and to let me know if that works for you on Windows that would be very useful. If it works I'll upload more of the old Pd-extended externals binaries.
Once we have a good set of externals live I guess it would make sense to tentatively let people on the Pd-list know about this method of obtaining externals.
Cheers,
Chris.
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
Thanks for sharing your workflows.
I'll try what you people are doing and see how far I come, though I somewhat sympathize with the idea of doing all in Debian (without wine/Windows VM). But let's try the established paths first.
Roman
On Sun, 2015-06-21 at 09:46 -0700, Miller Puckette wrote:
I compile externs both in mingw and in Microsoft Visual C running under wine (so both from linux). I keep a Windows XP machine around and crank it up to test things when I put out Pd releases, but all eh compiling happens in linux, and the first round of testing is under wine, which allows me to catch most problems without having to turn on Windows. (BTW my Windows machine is behind a firewall and has no name server configured in an attempt to keep whatever malware it's running from damaging anything. I recommend never putting a Windows machine where it can access the internet.)
cheers Miller
On Sun, Jun 21, 2015 at 08:17:03PM +0800, Chris McCormick wrote:
Hi,
On 21/06/15 18:13, Roman Haefeli wrote:
The new deken plugin makes me want to compile externals for Windows.
Any compiles and testing you can do with Deken on Windows is much appreciated, thank you so much.
What are people using? Are you compiling directly on Windows or are you cross-compiling from Linux? Are you going with the tool chain from your Distro or are you downloading the highest and latest manually?
So far in my limited experiments have been to upload existing externals from the last good build of the old Pd-extended binaries packages:
http://autobuild.puredata.info/auto-build/2013-08-08/
And then test them with Wine because my Windows XP virtualbox is doing the same thing you reported yours was doing in 2011 here:
http://lists.puredata.info/pipermail/pd-list/2011-11/092698.html
If you have a chance to try out the 'freeverb~' external I uploaded on a Pd-vanilla 0.46 from Miller and to let me know if that works for you on Windows that would be very useful. If it works I'll upload more of the old Pd-extended externals binaries.
Once we have a good set of externals live I guess it would make sense to tentatively let people on the Pd-list know about this method of obtaining externals.
Cheers,
Chris.
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
On Sun, 2015-06-21 at 20:17 +0800, Chris McCormick wrote:
If you have a chance to try out the 'freeverb~' external I uploaded on a Pd-vanilla 0.46 from Miller and to let me know if that works for you on Windows that would be very useful. If it works I'll upload more of the old Pd-extended externals binaries.
I tested on my work computer with Windows 7. Things seem to be slightly different in Windows 7 compared to Windows XP. The Deken documentation says it downloads and extracts externals to %AppData%\Pd. That is not the case on Windows 7. It seems Pd (and Deken) have %AppData% hard-coded to "%ProgramFiles%\Common Files", which seems wrong on Windows 7. On my box, %AppData% is set to C:\Users%UserName%\AppData\Roaming.
Deken can't download to '%ProgramFiles%\Common Files', because it would need higher privileges to do so. In order to still be able to test it, I created a symlink (I figured those exist in Windows,too) 'Pd' in % ProgramFiles%\Common Files pointing to C:\Users%UserName%\AppData \Roaming\Pd. Now, Deken was able to download the freeverb external, but it couldn't extract the package:
--- Unable to extract package automatically. Please perform the following steps manually: 1. Unzip C:/Program Files (x86)/Common Files/Pd/freeverb~(Windows-i386-32)-externals.zip. 2. Copy the contents into C:/Program Files (x86)/Common Files/Pd. ---
This is what I did (a Windows Explorer showing the contents of the archive popped up, so it was easy to move it to the correct place). Finally, I was able to load the external and I played around with the help-file. All seemed fine.
Probably the path issue needs to be already fixed in Pd?
I couldn't figure out why Deken cannot extract the archive on its own. Might this be also a privilege issue?
Roman
Hi Roman,
Thanks for following this up.
On 22/06/15 16:42, Roman Haefeli wrote:
Probably the path issue needs to be already fixed in Pd?
Martin Peach reported the exact same hevhaviour you experienced with Pd and paths.
How hard would it be for you to try this with the latest version of Pd from git on Windows? Miller merged a fix from IOhannes a while ago to do with Windows default search paths which might help this issue.
I couldn't figure out why Deken cannot extract the archive on its own. Might this be also a privilege issue?
Windows has no command line 'unzip' functionality (or indeed tar). TCL 8.6 ships with zlib so if/when Pd uses that version we will be able to do native unzip on Windows.
Cheers,
Chris.
On Mon, 2015-06-22 at 17:16 +0800, Chris McCormick wrote:
How hard would it be for you to try this with the latest version of Pd from git on Windows?
On a scale from 0 to 10? What is the pain of giving birth to a child on a scale from 0 to 10?
Miller merged a fix from IOhannes a while ago to do with Windows default search paths which might help this issue.
After several dead-ends (autotools: is that supposed to work also on Windows?), I managed to compile Pd on Windows XP (what an adventure..). For the record:
* mv pure-data pd * get / extract ASIO SDK to pd/asio * mkdir pd/bin * cd src; mingw32-make -f makefile.mingw
But it seems, I still cannot run Pd-vanilla on my Windows XP installations (VirtualBox and Hardware). Probably are both originating from the same medium.
Because IOhannes provided a fix, I then was also able to successfully cross-compile on Linux _with autotools_:
./configure --host i686-w64-mingw32 --prefix /opt/pd_win32/
So I used this build to test in wine, but I wasn't successful. When downloading freeverb with deken, Pd freezes just when the download has finished. wine then prints this to console:
潣汵湤琧攠數畣整∠湵楺≰›潮猠捵楦敬漠楤敲瑣牯൹^Cfixme:console:CONSOLE_DefaultHandler Terminating process 31 on event 0
(I hope it isn't saying anything indecent I don't understand)
I'll have to test tomorrow, when I have access to a Windows 7 box.
Roman
On 2015-06-23 00:54, Roman Haefeli wrote:
Because IOhannes provided a fix, I then was also able to successfully cross-compile on Linux _with autotools_:
./configure --host i686-w64-mingw32 --prefix /opt/pd_win32/
for the record: the fix mentioned can be found here [552].
we also needed to disable the building of the pd-watchdog for a successfull build (by removing it from src/Makefile.am:160).
it's unclear for me whether pd-watchdog *should* be build on W32 or not (as in: can it work at all or does it use POSIX foo (like "signals") that cannot work on W32?)
famsdr IOhannes
OK ... applied and pushed to git repo.
(I didn't test whether it resolved the "watchdog" problem though.)
I don't think pd-watchdog should be compiled on windows - there's no "rtprio" there to necessitate it.
cheers Miller
On Tue, Jun 23, 2015 at 09:34:43AM +0200, IOhannes m zmoelnig wrote:
On 2015-06-23 00:54, Roman Haefeli wrote:
Because IOhannes provided a fix, I then was also able to successfully cross-compile on Linux _with autotools_:
./configure --host i686-w64-mingw32 --prefix /opt/pd_win32/
for the record: the fix mentioned can be found here [552].
we also needed to disable the building of the pd-watchdog for a successfull build (by removing it from src/Makefile.am:160).
it's unclear for me whether pd-watchdog *should* be build on W32 or not (as in: can it work at all or does it use POSIX foo (like "signals") that cannot work on W32?)
famsdr IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
On Mon, 2015-06-22 at 17:16 +0800, Chris McCormick wrote:
Miller merged a fix from IOhannes a while ago to do with Windows default search paths which might help this issue.
I tested on Windows 7 and Pd does find deken in the right place now:
--- deken-plugin.tcl (Pd externals search) in C:/Users/rhaefeli/AppData/Roaming/Pd loaded. Platform detected: Windows-i386-32bit ----
However, when I download freeverb, I get (deken window):
--- can't create directory "C:/Program Files (x86)/Common Files/Pd": permission denied can't create directory "C:/Program Files (x86)/Common Files/Pd": permission denied while executing "file mkdir $::deken::installpath" (procedure "::deken::clicked_link" line 3) invoked from within "::deken::clicked_link .externals_searchui http://puredata.info/Members/chr15m/freeverb~(Windows-i386-32)-externals.zip freeverb~(Windows-i386-32)-exte..." (command bound to event) ----
Obviously, it still tries to download to the old path.
For loading externals, Pd apparently checks old and new style paths. Maybe deken just picks the first and doesn't try any other?
Roman
On 2015-06-23 09:08, Roman Haefeli wrote:
Obviously, it still tries to download to the old path.
For loading externals, Pd apparently checks old and new style paths. Maybe deken just picks the first and doesn't try any other?
exactly (that's how i programmed it).
the question is, why does it still try to use the old path? could it be something in the path settings?
could you do try the following?:
- start Pd - turn on the tcl prompt (Menu: Help -> Tcl prompt) - type in the tcl prompt run: ::pdwindow::post "$::sys_staticpath\n"
and see (and tell us) what it gives you.
fgamsdr IOhannes
On Tue, 2015-06-23 at 09:29 +0200, IOhannes m zmoelnig wrote:
the question is, why does it still try to use the old path? could it be something in the path settings?
could you do try the following?:
- start Pd
- turn on the tcl prompt (Menu: Help -> Tcl prompt)
- type in the tcl prompt run: ::pdwindow::post "$::sys_staticpath\n"
and see (and tell us) what it gives you.
Result:
{C:/Program Files (x86)/Common Files/Pd} C:/Users/rhaefeli/AppData/Roaming/Pd H:/Downloads/pd_compiled/pd_compiled/extra
So it seems that deken just picks the first which cannot be assumed to be always the correct one (fine for loading, bad for writing).
Roman
On Tue, 2015-06-23 at 10:04 +0200, Roman Haefeli wrote:
On Tue, 2015-06-23 at 09:29 +0200, IOhannes m zmoelnig wrote:
the question is, why does it still try to use the old path? could it be something in the path settings?
could you do try the following?:
- start Pd
- turn on the tcl prompt (Menu: Help -> Tcl prompt)
- type in the tcl prompt run: ::pdwindow::post "$::sys_staticpath\n"
and see (and tell us) what it gives you.
Result:
{C:/Program Files (x86)/Common Files/Pd} C:/Users/rhaefeli/AppData/Roaming/Pd H:/Downloads/pd_compiled/pd_compiled/extra
So it seems that deken just picks the first which cannot be assumed to be always the correct one (fine for loading, bad for writing).
When hard-coding to the second path in the list (deken:31):
set ::deken::installpath [ lindex $::sys_staticpath 1 ]
deken downloads to the "correct" (in W7) path. Of course, this is not a solution.
Isn't there a way to check for %AppData% independently from Pd?
Roman
On Tue, 2015-06-23 at 11:00 +0200, Roman Haefeli wrote:
On Tue, 2015-06-23 at 10:04 +0200, Roman Haefeli wrote:
On Tue, 2015-06-23 at 09:29 +0200, IOhannes m zmoelnig wrote:
the question is, why does it still try to use the old path? could it be something in the path settings?
could you do try the following?:
- start Pd
- turn on the tcl prompt (Menu: Help -> Tcl prompt)
- type in the tcl prompt run: ::pdwindow::post "$::sys_staticpath\n"
and see (and tell us) what it gives you.
Result:
{C:/Program Files (x86)/Common Files/Pd} C:/Users/rhaefeli/AppData/Roaming/Pd H:/Downloads/pd_compiled/pd_compiled/extra
So it seems that deken just picks the first which cannot be assumed to be always the correct one (fine for loading, bad for writing).
Setting line 31 to:
set ::deken::installpath $env(USERPROFILE)
makes deken download to the correct path in W7. Can't test in Windows XP right now.
On 2015-06-23 11:06, Roman Haefeli wrote:
set ::deken::installpath $env(USERPROFILE)
makes deken download to the correct path in W7. Can't test in Windows XP
are you sure? i would expect that to install to "%AppData%" rather than "%AppData%\Pd".
but probably the best solution would be to check all paths in ::sys_staticpath and use the first one that is writeable.
fgamsdr IOhannes
On Tue, 2015-06-23 at 13:08 +0200, IOhannes m zmoelnig wrote:
On 2015-06-23 11:06, Roman Haefeli wrote:
set ::deken::installpath $env(USERPROFILE)
makes deken download to the correct path in W7. Can't test in Windows XP
are you sure? i would expect that to install to "%AppData%" rather than "%AppData%\Pd".
Now, that you mention it, I wonder about it, too, but it really does download to "%AppData%\Pd". Anyway, it only works on Windows (probably not even on Windows XP). It's definitely not the solution.
but probably the best solution would be to check all paths in ::sys_staticpath and use the first one that is writeable.
What is the origin of ::sys_staticpath? Shouldn't normally the order be local first, system last? If the order of ::sys_staticpath would be "correct", it'd work on Windows XP _and_ Windows 7, right?
Roman
On Tue, 2015-06-23 at 14:39 +0200, Roman Haefeli wrote:
On Tue, 2015-06-23 at 13:08 +0200, IOhannes m zmoelnig wrote:
On 2015-06-23 11:06, Roman Haefeli wrote:
set ::deken::installpath $env(USERPROFILE)
makes deken download to the correct path in W7. Can't test in Windows XP
are you sure? i would expect that to install to "%AppData%" rather than "%AppData%\Pd".
Now, that you mention it, I wonder about it, too, but it really does download to "%AppData%\Pd".
Don't know what tricked me to believe it actually downloaded something to the folder I was watching. You're right, it doesn't.
Roman
On Tue, 2015-06-23 at 14:39 +0200, Roman Haefeli wrote:
On Tue, 2015-06-23 at 13:08 +0200, IOhannes m zmoelnig wrote:
On 2015-06-23 11:06, Roman Haefeli wrote:
set ::deken::installpath $env(USERPROFILE)
makes deken download to the correct path in W7. Can't test in Windows XP
are you sure? i would expect that to install to "%AppData%" rather than "%AppData%\Pd".
Now, that you mention it, I wonder about it, too, but it really does download to "%AppData%\Pd". Anyway, it only works on Windows (probably not even on Windows XP). It's definitely not the solution.
but probably the best solution would be to check all paths in ::sys_staticpath and use the first one that is writeable.
What is the origin of ::sys_staticpath? Shouldn't normally the order be local first, system last? If the order of ::sys_staticpath would be "correct", it'd work on Windows XP _and_ Windows 7, right?
On Linux, the order seems to be local first, system last:
::pdwindow::post "$::sys_staticpath\n"
/home/roman/pd-externals /usr/local/lib/pd-externals /usr/local/lib/pd/extra
I guess if we have that on Windows, too, things should work fine.
Roman
On 2015-06-23 15:01, Roman Haefeli wrote:
On Linux, the order seems to be local first, system last:
yes, that is what my flawed logic was based upon...
I guess if we have that on Windows, too, things should work fine.
i think the better approach is to filter the non-writable directories from the list before selecting one as the destination.
Fixed in https://github.com/pure-data/deken/issues/49
fgmasdr IOhannes
On Tue, 2015-06-23 at 15:31 +0200, IOhannes m zmoelnig wrote:
On 2015-06-23 15:01, Roman Haefeli wrote:
On Linux, the order seems to be local first, system last:
yes, that is what my flawed logic was based upon...
Why flawed?
I guess if we have that on Windows, too, things should work fine.
i think the better approach is to filter the non-writable directories from the list before selecting one as the destination.
Cool.
Before I knew about your fix, I also submitted a patch to sourceforge for pure-data that changes the order of sys_staticpath for Windows, so that your 'flawed logic' wouldn't be flawed. I'd say it would make sense anyway to change the order, not only for deken, but it seems to be common notion that local paths are checked first, global last.
https://sourceforge.net/p/pure-data/patches/553/
I tested on Windows 7 with above patch applied and deken downloads to the correct location.
Roman
On 2015-06-21 12:13, Roman Haefeli wrote:
Hey all
The new deken plugin makes me want to compile externals for Windows. There seem to be many ways to go and I might save some time if I knew beforehand what works and what no so well. I have access to the following archs:
- Debian 7 (i386, amd64, armv6l)
- Debian 8 (i383, amd64)
- Ubuntu 14.04 (i386, amd64)
- Windows XP (w32)
What are people using? Are you compiling directly on Windows or are you cross-compiling from Linux? Are you going with the tool chain from your Distro or are you downloading the highest and latest manually?
for W32 i mainly cross-compile using mingw64 (http://mingw-64.org), then test under a virtual machine.
mingw on w32 never really worked for me. iirc i have had some bad experiences with cross compiling linux->w32 using mingw (http://mingw-64.org).
but mingw64 is just great and allows me to virtually compile everything i want (apart from some Gem plugins that use a C++-library that i only have available (if at all) as a visual-c++ pre-compiled binary (and there's some ABI incompatibility between g++ and MSVC++)
my build system is Debian testing/unstable amd64, which comes with mingw64. while experimenting with tavis-ci for cross-builds¹, i noticed that the version of mingw64 that is available on travis-ci (which runs Ubuntu-12.04LTS) is too old, as it doesn't come with proper pthreads support.
as for dependencies, i often ended up just fetching the source-code and building the dependencies in a pre-build step (part of the automatisation). this mainly works because the libraries i use most often are linux-centric (so they come with proper autotools support; and are available for download of course...)
fmgasd IOhannes
¹ e.g. for https://github.com/iem-projects/pd-iem, which is being a bit obsoleted by deken and friends (otoh this project was mainly about compiling the libs, rather than making them available).
On 2015-06-21 12:13, Roman Haefeli wrote:
On a related note: How feasible is it to cross-compile for Mac OS X?
i never tried, since you can install a proper toolchain (that can handle GNU makefiles and autotools) on OSX easy enough (unlike W32 where i found it virtually impossible)
fsmdr IOhannes
On 2015-06-22 09:17 AM, IOhannes m zmoelnig wrote:
On 2015-06-21 12:13, Roman Haefeli wrote:
On a related note: How feasible is it to cross-compile for Mac OS X?
i never tried, since you can install a proper toolchain (that can handle GNU makefiles and autotools) on OSX easy enough (unlike W32 where i found it virtually impossible)
Building natively on Win32 (Windows 8.1 SmScrn Touch actually) worked for me. An up to date description is at http://puredata.info/docs/developer/WindowsMinGW/. But I admit not using the autotools.
fsmdr IOhannes
Greetings,
Fred Jan
On Sun, Jun 21, 2015 at 12:13 PM, Roman Haefeli reduzent@gmail.com wrote:
On a related note: How feasible is it to cross-compile for Mac OS X?
Very simple by using this: https://github.com/tpoechtrager/osxcross
It was easy to install, and it even maps macports, so you can for instance write "osxcross-macports install libsamplerate" to install the libsamplerate package from macports if you want to cross-compile a program which uses libsamplerate.
Hi,
Roman Haefeli schrieb am 21.06.2015 12:13:
Hey all
The new deken plugin makes me want to compile externals for Windows. There seem to be many ways to go and I might save some time if I knew beforehand what works and what no so well. I have access to the following archs:
- Debian 7 (i386, amd64, armv6l)
- Debian 8 (i383, amd64)
- Ubuntu 14.04 (i386, amd64)
- Windows XP (w32)
What are people using? Are you compiling directly on Windows or are you cross-compiling from Linux? Are you going with the tool chain from your Distro or are you downloading the highest and latest manually?
Sorry to be late to join the party, but here is my approach to cross compilation for Windows on Linux:
I am using the Makefile template from Pd extended for PuREST JSON and mxe (Formerly known as MinGW Cross Environment: http://mxe.cc/). In fact, for me this is simpler than compiling on Windows, so I cross-compile and just transfer the dll to Windows for testing.
My changes to the Makefile are adding path variables to enable cross compilation: https://github.com/residuum/PuRestJson/commit/7a34c7fd3fe5a83b9ca53ac3fe2cc8...
For compilation, I set these variables as well as the UNAME variable, see: https://github.com/residuum/PuRestJson/wiki/Compilation#cross-compilation-fo...
On a related note: How feasible is it to cross-compile for Mac OS X?
I have not had the time to test that already, as I do not have a Mac handy for testing. As someone already mentioned, https://github.com/tpoechtrager/osxcross looks like a viable solution.
Hth, Thomas
Hi,
I recently setup several project to crossbuild with Mingw-w64 from Linux with C++11 thread support. Since it took some time to setup the toolchain, I put it online at [1]. I also setup some CI server to build for 4 architecture (Linux x86_64, Raspberry Pi, Win32 and Mac OS X) each push on my project [2]. This is pretty useful.
Cheers
Antoine
[1] : https://github.com/avilleret/mingw-w64 [2] : https://travis-ci.org/jamoma/JamomaPureData
-- do it yourself http://antoine.villeret.free.fr
2015-06-25 17:11 GMT+02:00 Thomas Mayer thomas@residuum.org:
Hi,
Roman Haefeli schrieb am 21.06.2015 12:13:
Hey all
The new deken plugin makes me want to compile externals for Windows. There seem to be many ways to go and I might save some time if I knew beforehand what works and what no so well. I have access to the following archs:
- Debian 7 (i386, amd64, armv6l)
- Debian 8 (i383, amd64)
- Ubuntu 14.04 (i386, amd64)
- Windows XP (w32)
What are people using? Are you compiling directly on Windows or are you cross-compiling from Linux? Are you going with the tool chain from your Distro or are you downloading the highest and latest manually?
Sorry to be late to join the party, but here is my approach to cross compilation for Windows on Linux:
I am using the Makefile template from Pd extended for PuREST JSON and mxe (Formerly known as MinGW Cross Environment: http://mxe.cc/). In fact, for me this is simpler than compiling on Windows, so I cross-compile and just transfer the dll to Windows for testing.
My changes to the Makefile are adding path variables to enable cross compilation:
https://github.com/residuum/PuRestJson/commit/7a34c7fd3fe5a83b9ca53ac3fe2cc8...
For compilation, I set these variables as well as the UNAME variable, see:
https://github.com/residuum/PuRestJson/wiki/Compilation#cross-compilation-fo...
On a related note: How feasible is it to cross-compile for Mac OS X?
I have not had the time to test that already, as I do not have a Mac handy for testing. As someone already mentioned, https://github.com/tpoechtrager/osxcross looks like a viable solution.
Hth, Thomas
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
-
Antoine Villeret -
Chris McCormick -
Fred Jan Kraan -
IOhannes m zmoelnig -
Kjetil Matheussen -
Miller Puckette -
Roman Haefeli -
Thomas Mayer