5 ms·

Paradoxically, I find it easier to port applications to Windows than MacOS. Due to the efforts from the Cygwin and MSYS groups, just about every build script p

by kxyvr 10y ago

Paradoxically, I find it easier to port applications to Windows than MacOS. Due to the efforts from the Cygwin and MSYS groups, just about every build script ports naturally to Windows. As long as I use MinGW, the resulting application is native and can be distributed. On MacOS, there's a bunch of quirks that make it harder to port. Environment variables are different enough to require duplication in scripts (DYLD_LIBRARY_PATH instead of LD_LIBRARY_PATH, unless we need DYLD_FALLBACK_LIBRARY_PATH.) Certain utilities like gdb will not run because System Integrity Protection disallows them. In theory, we can sign gdb through a somewhat circuitous series of steps, except that this doesn't work if we want to ssh into the box. This requires turning off SIP, modifying some files, and then turning SIP back on. Technically, it's all possible, but it's one series of aggravations after another. Developing on a platform should not be this difficult.

danieldk 10y ago
On MacOS, there's a bunch of quirks that make it harder to port. Environment variables are different enough to require duplication in scripts (DYLD_LIBRARY_PATH instead of LD_LIBRARY_PATH, unless we need DYLD_FALLBACK_LIBRARY_PATH.) I use CMake and it's a walk in the park. I just install the dependencies using Homebrew. CMake adds all the necessary include/library flags and builds the application bundle. It's even much easier than Linux, where building a package on the next Ubuntu LTS is always a bit of a drag (updated dependencies, changed library paths, etc.). Windows, in contrast, has been hell. Some of the dependencies of one particular project only compile with Visual Studio on Windows, not Cygwin/MingW. So, the only reasonable way to compile the application is to get VC++-compiled versions of zlib, libxml, etc. Since everything does not have canonical UNIX paths, you end up a lot of paths manually in CMake. And then you have to deal with things such as VC's standard library not having getopt, etc. For me, macOS is the most comfortable development environment by far. Except that they should put out a Mac Pro with replaceable GPUs again. I use CUDA a lot, so the only practical option is Linux.
- pawadu 10y ago
  > Windows, in contrast, has been hell. Some of the dependencies of one particular project only compile with Visual Studio on Windows, not Cygwin/MingW. Seems like the issue is with the particular project you are trying to compile and you are blaming it on the OS. Also, Visual Studio has its own package manager with tons of libraries and tools.
  - danieldk 10y ago
    I am not blaming Windows. It's just that Windows is a mismatch for projects that come from a UNIX tradition. I work in a field where most software is UNIX-first (ML/NLP), so Windows was virtually never a serious option as a development environment. Of course, much of changes now with Windows Subsystem for Linux.
- kxyvr 10y ago
  I use Homebrew and CMake as well, but it certainly has not been as smooth as my CMake scripts contain a series of fixes for MacOS. I also like CPack, but there's been less consistency with MacOS. Bundles don't work for multilanguage libraries since things like mex files can't be packaged as a framework. PackageMaker was deprecated since Yosemite. OSXX11 is really X11 specific. DragNDrop sort of works, but it can't run any post install scripts to do things like set environment variables, which, again, the process for doing so changes from release to release and whether or not we're on the console. Conversely, the WIX generator on Windows allows me to package everything as I need it to. Though less nice, NSIS also works well. Certainly, that's not to say that everything is rosy and cherry on Windows. I just did a cold build from scratch on a new Windows license and it honestly went as well as it did because I know exactly which tools to get. Mostly, it's that after banging my head against both the Windows and MacOS ecosystems, I can build a new development system vastly faster on Windows and have few headaches. As a quick note, thank god for the Homebrew crew as that does make things much nicer. As a final note, some of these headaches would immediately disappear if I could virtualize MacOS since it would fix the console login vs desktop login problems. Also, I could actually fix problems when working on an airplane.
vetinari 10y ago
I usually avoid MinGW, because it links your binaries agains msvcrt.dll. It really shouldn't do it - https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=1273 https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=...
- kxyvr 10y ago
  I haven't tried in awhile, but is the best option just to use VC directly at this point?
  - vetinari 10y ago
    Probably yes, but on the other hand, VC is incapable of building some FOSS packages (xz comes to mind).
  - tavert 10y ago
    If everything is using cmake, and you don't need any inline assembly or fortran for scientific code, then maybe. But you end up in a parallel universe where everything that touches MSVC is just needlessly different than every other platform. If mingw gcc is working for you, then it's much easier for dev skills to transfer between building for Windows and building for unix. If you do need inline assembly and/or Fortran (LAPACK anyone?) then it's easiest to pretend visual studio doesn't exist.
    - kxyvr 10y ago
      Well, and that's the trick. Originally, I shied away from VC because I link into LAPACK. Even if I hook into a precompiled library from a manufacturer, they use the same name mangling scheme as Fortran. In order to figure that out, both autotools and CMake compile a small Fortran program and check, which means that I need a Fortran compiler. Technically, I could set a macro to the name mangling by hand since there's only four possibilities, but it's a little irritating. I suppose that I could use VC for the C++ pieces and gfortran for the Fortran pieces, but it's always been easier just to use MinGW.

by kxyvr 10y ago

danieldk 10y ago

On MacOS, there's a bunch of quirks that make it harder to port. Environment variables are different enough to require duplication in scripts (DYLD_LIBRARY_PATH instead of LD_LIBRARY_PATH, unless we need DYLD_FALLBACK_LIBRARY_PATH.) I use CMake and it's a walk in the park. I just install the dependencies using Homebrew. CMake adds all the necessary include/library flags and builds the application bundle. It's even much easier than Linux, where building a package on the next Ubuntu LTS is always a bit of a drag (updated dependencies, changed library paths, etc.). Windows, in contrast, has been hell. Some of the dependencies of one particular project only compile with Visual Studio on Windows, not Cygwin/MingW. So, the only reasonable way to compile the application is to get VC++-compiled versions of zlib, libxml, etc. Since everything does not have canonical UNIX paths, you end up a lot of paths manually in CMake. And then you have to deal with things such as VC's standard library not having getopt, etc. For me, macOS is the most comfortable development environment by far. Except that they should put out a Mac Pro with replaceable GPUs again. I use CUDA a lot, so the only practical option is Linux.

pawadu 10y ago
> Windows, in contrast, has been hell. Some of the dependencies of one particular project only compile with Visual Studio on Windows, not Cygwin/MingW. Seems like the issue is with the particular project you are trying to compile and you are blaming it on the OS. Also, Visual Studio has its own package manager with tons of libraries and tools.
- danieldk 10y ago
  I am not blaming Windows. It's just that Windows is a mismatch for projects that come from a UNIX tradition. I work in a field where most software is UNIX-first (ML/NLP), so Windows was virtually never a serious option as a development environment. Of course, much of changes now with Windows Subsystem for Linux.
kxyvr 10y ago
I use Homebrew and CMake as well, but it certainly has not been as smooth as my CMake scripts contain a series of fixes for MacOS. I also like CPack, but there's been less consistency with MacOS. Bundles don't work for multilanguage libraries since things like mex files can't be packaged as a framework. PackageMaker was deprecated since Yosemite. OSXX11 is really X11 specific. DragNDrop sort of works, but it can't run any post install scripts to do things like set environment variables, which, again, the process for doing so changes from release to release and whether or not we're on the console. Conversely, the WIX generator on Windows allows me to package everything as I need it to. Though less nice, NSIS also works well. Certainly, that's not to say that everything is rosy and cherry on Windows. I just did a cold build from scratch on a new Windows license and it honestly went as well as it did because I know exactly which tools to get. Mostly, it's that after banging my head against both the Windows and MacOS ecosystems, I can build a new development system vastly faster on Windows and have few headaches. As a quick note, thank god for the Homebrew crew as that does make things much nicer. As a final note, some of these headaches would immediately disappear if I could virtualize MacOS since it would fix the console login vs desktop login problems. Also, I could actually fix problems when working on an airplane.

vetinari 10y ago

I usually avoid MinGW, because it links your binaries agains msvcrt.dll. It really shouldn't do it - https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=1273 https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=...

kxyvr 10y ago
I haven't tried in awhile, but is the best option just to use VC directly at this point?
- vetinari 10y ago
  Probably yes, but on the other hand, VC is incapable of building some FOSS packages (xz comes to mind).
- tavert 10y ago
  If everything is using cmake, and you don't need any inline assembly or fortran for scientific code, then maybe. But you end up in a parallel universe where everything that touches MSVC is just needlessly different than every other platform. If mingw gcc is working for you, then it's much easier for dev skills to transfer between building for Windows and building for unix. If you do need inline assembly and/or Fortran (LAPACK anyone?) then it's easiest to pretend visual studio doesn't exist.
  - kxyvr 10y ago
    Well, and that's the trick. Originally, I shied away from VC because I link into LAPACK. Even if I hook into a precompiled library from a manufacturer, they use the same name mangling scheme as Fortran. In order to figure that out, both autotools and CMake compile a small Fortran program and check, which means that I need a Fortran compiler. Technically, I could set a macro to the name mangling by hand since there's only four possibilities, but it's a little irritating. I suppose that I could use VC for the C++ pieces and gfortran for the Fortran pieces, but it's always been easier just to use MinGW.