]]>
]]>
I naively started to do the modules on windows with the free version of microsoft visual thing but...
I'm planning to start to do some openframeworks expériment for linux app as well as being able to compile Usine module for Mac...
So a cross plateform developpement tool like code blocks could be the one ?
what do you think ?
cheers
Statistics: Posted by oli_lab — 15 Jan 2016, 14:23
]]>
]]>
]]>
The SDK does have cross-platform functions to help with the GUI so you do not need to write separate code for OSX / Windows if you use those. However, on Windows it looks like those cross-platform functions use the gdiplus libraries so are not compatible with mingw without a fair bit of hassle.
Statistics: Posted by caco — 27 Aug 2013, 14:54
]]>
I assumed that graphical stuff would be abstracted by the SDK, which seems like it would be the only sane way to have an SDK that is intended to support both platforms...
I don't have much experience with SDK's and compiled languages, so apologies if what I'm saying sounds stupid. But it seems to me that the SDK itself should be able to link to GDI/MFC/whatever other horrible Windows API/etc without the end user having to worry about that. Probably I'm totally wrong here.
Either way, forcing any SDK user to do separate GUI programming paths for either Windows and OS X seems like a truly annoying anti-pattern.
Statistics: Posted by ceasless — 27 Aug 2013, 13:15
]]>
I converted the Usine 5 SDK to compile using mingw for my old user modules and it was fairly trivial to do. I have not had time yet to look at doing the same for Hollyhock's SDK although I suspect I will be more difficult as I spotted that some of the examples use GDI Plus for drawing the graphics with in Windows. The GDIPlus headers do not come included with mingw due to license restrictions and (last time I checked) required lots of modifications to force them to work with the mingw compiler.
Statistics: Posted by caco — 27 Aug 2013, 09:18
]]>
]]>
i just come back from holidays and i see you are quit active in the sdk area
well said, code sharing is the key for user modules.With the outcomming of Hollyhock there's a need to share the sources, not only the binaries!
Most of us have only access to a win or a mac. But plugins should be usable on both worlds, so users of the "opposite" OS should have the chance to complile the plugin themself.
it's crucial to have a maximum of user modules available on all platform, we are intensively thinking about it, not yet found a good solution...
good idea,Transforming some of the ideas into a wiki page "Best practise Holyhock binary development" should stand be the end of this thread.
for sure, there is a huge work to do on the sdk wiki and i have no time (for now) to simply make it
any collaboration/help is welcome
about source repo :
-we use SVN internally for the sdk
-a public repo for user modules is the way to go, but we have not yet decided what form it might take
Statistics: Posted by martignasse — 26 Aug 2013, 14:45
]]>
I'm starting a new project and I think it's a good idea using something like git or an other repository for codemanagement. Form my point it my be a good idea to have something I would call a "prefered process for sources management" in Usine development (or call it best practice)
With the outcomming of Hollyhock there's a need to share the sources, not only the binaries!
Most of us have only access to a win or a mac. But plugins should be usable on both worlds, so users of the "opposite" OS should have the chance to complile the plugin themself.
I would like to start here a collection of ideas here.
Best practice
- this coding rules are mandantory: http://sensomusic.org/wiki2/doku.php?id=sdk_hollyhock:coding_rules
- using a plattform neutral framework is a good idea (e.g. I had good results with boost underneaht Usine 5.x)
- Plattform differences should be handled in all programms in the same way. E.g. with standard defines (as described in the sdk wiki) and/or seperate source trees/files if defines make the codes unreadable.
- Using for all the same repo style would allow to create some standard build scripts for all plugins.
- This means e.e. using pathes in a similar definition like in MAVEN repos.
- maybe Sensomusic can host once a small repo here like a git or so..
:-)Transforming some of the ideas into a wiki page "Best practise Holyhock binary development" should stand be the end of this thread.
Peter
Statistics: Posted by hesspet — 26 Aug 2013, 12:08
]]>