Problems with Windows build VS 2012

[Falko]

Hello,

I am trying to build the current dev version of tuttle from source (git clone --recursive ...), My goal is to have one tuttle-plugin library to use in my own project. I tried to build this naively (default settings, at first did not look at individual cmake files) on a Windows 8.1 machine with Visual Studio 2012, 64bit.

By now I identified the following build related issues 

breaks compilation, cmake issues:

- plugin targets do not inherit boost_LIBRARY_DIR and can not find boost libs

- plugin target properties use Linux link flags because there is only cases for Mac and Non-Mac

- plugins link against dl library, which is not available on Windows

- dll entry points can not be exported the way it is done now. If tuttlePluginLib is build statically, then the plugin dlls need to export the functions themselves, it can not be done at compile time of tuttlePluginLib. If it were built dynamically, then still the actual plugin (

breaks compilation, source issues:

- signal handler in sam uses "strsignal", not available in Windows

- current SequenceParser version has several API changes

breaks single plugins:

- bitdepthplugin and dpxwriterplugin fail to compile because their compilation units get too large, should be compiled with /bigobj 

wishlist:

- cmake should use static boost libs per default on Windows

- sequenceparser should be build static per default on Windows

Please let me know if this is the right place to adress this, if you need any further information or if I just did anything wrong and should do stuff differently to start with.

Greets!

Falko

[Clément Champetier]

On Friday, 5 June 2015 16:14:33 UTC+2, Falko wrote:

Hello,

Hello Falko,

 

I am trying to build the current dev version of tuttle from source (git clone --recursive ...), My goal is to have one tuttle-plugin library to use in my own project. I tried to build this naively (default settings, at first did not look at individual cmake files) on a Windows 8.1 machine with Visual Studio 2012, 64bit.

By now I identified the following build related issues 

breaks compilation, cmake issues:

- plugin targets do not inherit boost_LIBRARY_DIR and can not find boost libs

Which version of CMake do you use?

 

- plugin target properties use Linux link flags because there is only cases for Mac and Non-Mac

We recently switch from scons to CMake build system. This recent work was not tested on Windows...

 

- plugins link against dl library, which is not available on Windows

I don't understand... Can you quote some lines in CMake files?

 

- dll entry points can not be exported the way it is done now. If tuttlePluginLib is build statically, then the plugin dlls need to export the functions themselves, it can not be done at compile time of tuttlePluginLib. If it were built dynamically, then still the actual plugin (

Indeed some work must be done to export all classes for dll on Windows.

See this related discussion: https://groups.google.com/forum/#!topic/tuttleofx-dev/sUFC7YJ15V0

 

breaks compilation, source issues:

- signal handler in sam uses "strsignal", not available in Windows

- current SequenceParser version has several API changes

We agree that sam tools have some problems, like UNIX dependencies, and the dependency to an old SequenceParser version.

Currently we work on a new version of sam tools, in python : https://github.com/cchampet/TuttleOFX/tree/dev_samInPython.

But you said you had a problem to compile the project because of the SequenceParser submodule?

Did you do: git submodule -i update

The SequenceParser submodule should compile with sam tools on develop branch (see travis CI: https://travis-ci.org/tuttleofx/TuttleOFX).

 

breaks single plugins:

- bitdepthplugin and dpxwriterplugin fail to compile because their compilation units get too large, should be compiled with /bigobj 

I was not aware of this issue. Thanks. 

 

wishlist:

- cmake should use static boost libs per default on Windows

Each plugins depend on boost libraries. If they are linked against boost static libs, the binaries will be much more bigger. But I agree this should be possible.

 

- sequenceparser should be build static per default on Windows

SequenceParser is built both statically and dynamically. But only dynamic libs are used for linking. And same as boost libraries, each plugins depend on sequenceParser.

 

Please let me know if this is the right place to adress this, if you need any further information or if I just did anything wrong and should do stuff differently to start with.

Your are in the right place to discuss about that ;)

Can you open issues on the github repository, for each independent problem you've mentioned above?

The next step will be to work on each problems. Feel free to contribute with us :)

 

Regards,

Clement

Greets!

Falko

[Falko Kellner]

Hello Clement,

I am using cmake 3.0.1 and newer, but if the build process in general is not tested on Windows yet, it is natural it doesnt work out of the box.

As for the .dlls, I want to implement one or two plugins with rather simple functionality using the tuttle library and plan to ship only those. It looks a little over the top if I deliver hundreds of 3rd party dlls for a basic functionality. The windows tuttle binary distribution on the website does not ship any dlls, so I thought that this might have been compiled statically?

I will look at the github bug tracker asap

Greets and thanks for your help

Falko

--

---
Vous recevez ce message, car vous êtes abonné à un sujet dans le groupe Google Groupes "tuttleofx-dev".
Pour vous désabonner de ce sujet, visitez le site https://groups.google.com/d/topic/tuttleofx-dev/bj8Pn4STL1U/unsubscribe.
Pour vous désabonner de ce groupe et de tous ses sujets, envoyez un e-mail à l'adresse tuttleofx-de...@googlegroups.com.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.