generic question about binaray development - repository for sources

[hesspet]

Hi,

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

[martignasse]

hi hesspet,

i just come back from holidays and i see you are quit active in the sdk area

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.

well said, code sharing is the key for user modules.
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...

Transforming some of the ideas into a wiki page "Best practise Holyhock binary development" should stand be the end of this thread.

good idea,
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

[ceasless]

One solid thing to consider would be to encourage (or even require, since it is completely free) the use of Code::Blocks for user modules. This IDE exists on both platforms and theoretically a cross-platform build setup template could be used for all projects.

[caco]

It's not really code::blocks that is the important part, rather it is the compiler it uses. It the case of code::blocks this is often (but not always) mingw which is the windows equivalent of Mac's GCC.

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.

[ceasless]

Hmm.. I recommended Code::Blocks because in my experience it is the easiest way to get mingw set up on Windows.

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.

[caco]

I may be wrong as i haven't spent much time yet with Hollyhock's SDK...

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.

[ceasless]

That's a shame. I've always tried to avoid using Visual Studio. It's nice that MS at least provides the free 'Express' version these days (thanks to competition from free compilers like mingw, I'm sure).

[caco]

For my Usine v5 user modules I coded the GUI using anti grain geometry which worked fine using code::blocks mingw so there are cross-platform mingw-friendly alternatives out there if anyone fancies having a go. Sadly I do not think I have time at the moment.

[oli_lab]

Hi !
would you still recommend to use code::blocks now ?

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

[23fx23]

Personally i spent ages making thing work with codeblocks and could never get it work whereas it was instant working on Vs. Ifind also the way to code much more user friendly on vs wich got a fully free functional vers. mind you im still a noob in coding but I think we don t need to use only one tool but the one we prefer as long as it compiles (mean i wont get back to codeblocks pers :p)

[oli_lab]

I'll take your point serously as I'm a sort of a noob myself