btw, i really think that the installer should use as much of cmake as possible. not necessarily for a build environment, but more for a development environment.

I am not sure what you mean. The installer-script only runs after make bundle has already done it's job...

the development workflow is basically relies on a working make install target, which should bundle all required dlls etc. (which is currently done in the make package build step). but afaict, this is required otherwise one will have a hard time when debugging ... in case anyone has the absurd idea to start debugging sc on windows

I don't think so. On Windows there is a required "make bundle" build step (target) that brings together all required files for a working SC in the install folder. Make package is not required - it is only used to create an installer executable, and with my additions to present SC with a friendly intro to a Windows system (and if required a clean outro) ;)

btw, i really think that the installer should use as much of cmake as possible. not necessarily for a build environment, but more for a development environment.

Tim, could you please clarify this?

CPack is not good for Windows, misses features we desire. Hence custom NSIS script. Or what do you mean?

Maybe - at least for the record - it is good to add some considerations here:

• the manual 'make bundle' is not available as build-steps on Mac and sc3-plugins - so one might overlook it
• the code for 'make bundle' is quite intransparent to me, but it works, provided it can somehow identify the location
  of required libraries. I solved this by adding all such locations to the system path (msys) - I am sure there is a better way, but I don't know it. In Qt Creator you can extend the system path temporarily for build requirements only. So I don't have to mess up my global Windows system path, which is nice. Make bundle is very slow though (10 Mins or more), I am sure it could do with some love. (I didn't touch it)
• as to cpack vs. NSIS:
  • I didn't look deeply into cpack, I just built on top of the existing script. The sources indicated that cpack was missing useful features like an option for the selection of install components. This is not required right now, as sced is gone, but it is easy to imagine a deluxe installer with components in the future: command line only, supernova, sc3-plugins
  • using NSIS might be helpful for people compiling with MSVC too
  • NSIS is readily available, omnipresent, libre and mature, so a case of an "easy" dependency

Let me add a wild guess at what Tim is actually hinting: If we discuss setting up a development system that allows proper debugging, I am all for it, although this is considerably beyond my low level of expertise (and on a side note this is not related to creating a Windows installer executable).

So when we talk about a "development environment": I can now compile SC in Qt Creator by pressing the button run - as well as debug run. This runs the entire build process (if required) and then tries to start scsynth. It currently fails because command line arguments are required.

Now let's take an example: the current serious network bug on Windows could be reproduced by running sclang. To run it in a debug environment, I assume it would be necessary to make Qt Creator start sclang in debug mode and then start scsynth (or supernova) from the readline interface. So I'd somehow have to make Qt Creator (or cmake?) build and then start sclang? If you'd briefly describe the required steps to get to this point, I'd happily follow them and try to learn what is implied - and then report the output.

So two examples would be really helpful:

• how make Qt Creator target scsynth (or supernova) and start it with the required command line arguments
• how make Qt Creator target sclang

PS: a new obstacle: when trying to run sclang just now I found that the readline interface currently interprets every keystroke as ctrl-d and immediately quits - grrr. I'll try to find out what's going on later

problem is that make install does not result in a working binary, as the dlls are not copied.

So you're basically saying the current make bundle step should be integrated into the make install step. Makes sense. Currently make bundle takes 10 mins though and requires the system path to be adjusted. Would be nice to fix that in one step. The nice thing about make bundle is that it finds the required libraries intelligently, that capability seems useful and we wouldn't want to lose that by adding a static list of libraries to be copied that would have to be maintained. From Qt4.8.4 to 4.8.5 e.g. zlib1.dll became required - you wouldn't want to have to take care of that.

yes, the make bundle step should go into make install ... it is exactly the same situation as on osx when creating an app bundle

I will have another look into the osx-file, but I doubt I can come up with something that is good enough. Let's see...
Thanks for the ASIO fix, btw, I will test it later today!

the code for 'make bundle' is quite intransparent to me, but it works, provided it can somehow identify the location of required libraries. I solved this by adding all such locations to the system path (msys) - I am sure there is a better way, but I don't know it.

1. Initialize CMake with a toolchain file:
   cmake -DCMAKE_TOOLCHAIN_FILE=<my_file> ..
2. In the toolchain file, set CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH to lists of include dirs and binary dirs of dependencies.

Will try! Thanks!

actually, some find_package scripts define XXX_LIBRARY_DIRS variables which can be used to locate shared libraries in fixup_bundle.

So I looked into the toolchain file again and after some trial and error, I got it. This works nicely on my system with one exception (and it builds on environment variables I have defined):

SET(CMAKE_LIBRARY_PATH $ENV{DEPS_PREFIX}/libsndfile/bin; $ENV{DEPS_PREFIX}/fftw3.org; $ENV{DEPS_PREFIX}/portmidi/lib; $ENV{DEPS_PREFIX}/portaudio/lib; $ENV{DEPS_PREFIX}/readline/bin; $ENV{QT_BIN}; $ENV{MINGW_BIN}; $ENV{PORTED_BIN}; ) SET(CMAKE_INCLUDE_PATH $ENV{DEPS_PREFIX}/libsndfile/include; $ENV{DEPS_PREFIX}/fftw3.org; $ENV{DEPS_PREFIX}/portmidi/common; $ENV{DEPS_PREFIX}/portmidi/porttime; $ENV{DEPS_PREFIX}/portaudio/include; $ENV{DEPS_PREFIX}/readline/include )

The exception is realine, the library of which is not found. If I add libreadline6 (and maybe libreadline5 - it's in implicit version check, right?) in the third line of FindReadline.cmake, this library is found like the others.

I like the use of of the toolchain file, it's a nice intermediary between the host-environment on one side and the generic build requirements on the other hand. It allows to keep project-specific settings out of the system (path) and system-specific static settings out of the list of cmake -D-arguments. It also seems to override find paths in the FindXXX.cmake modules, which can be good thing (The find routines can have unintended hit's if you have a default install of one of the dependencies on your system, which you do not want to include in the compile. I had such a case with libsndfile once - and you are likely to not even note that it happens).

Yet in terms of speed this addition doesn't seem to make a significant difference for make bundle (compared to adding library-paths to the system path). So maybe we have to live with it's duration? In the past I had a script that copied all libraries, and that just took a second or so, but I prefer the "intelligence" of make bundle. It takes ages, though, seems to be verifying individual files.

Would it make sense to add libreadline6 (and 5) to FindReadline.cmake? Could you do it? Pushing a pull-request for such a tiny change seems a bit unproportional...

Best
.r.

Finally, I managed to produce a working windows build, and I merged in your improvements. Thanks a million for all this!

Cool! Thanks too for all your Windows efforts!