Questions, bug reports, features requests, ... about the Oric Software Development Kit. Please indicate clearly in the title the related element (OSDK for generic questions, PictConv, FilePack, XA, Euphoric, etc...) to make it easy to locate messages.

The article below explain how to convert VS projects to Eclipse CDT, AFAIK it also exist on Linux and OSX.
If the OSDK do not use specifcs stuff from Windows/VS then we could compile from Eclipse the OSDK to Linux and OSX.
Newer version of VS do not contain the export function.
Kamel

I hate Eclipse with passion
If we wanted a multi-platform build, the solution would be to have a makefile and use gcc, not use a different IDE.
I once tried to convert the osdk to use gcc (mingw on windows) but there was problems with FreeImage that did not compile cleanly.

Long postponed, but today I made quick port of OSDK for Linux 32/64.
It uses standard features (make, sh, etc. so probably will work in OSX too).
Foreseen is to be build out of main OSDK tree for easy support.
If there is interest I'll be happy to:
- supply patch for the current OSDK in SVN;
- commit changes to SVN (after approval of course);
- send zipped package 32/64 bit.

As long as the Original Windows version with batch files still work, and that's it's easy to know what is linux and what is version (separate bin folders, ...) I'm fine with that.
Perhaps check with mmu_man for your changes, he was also working on Linux changes of the sdk.

I prepared osdk - the Linux port of the OSDK as git repository hosted at BitBucket: https://bitbucket.org/iss/osdk.
Info about installation and basic usage can be found in README file.
Last added utilities makedisk, mym2ym and ym2mym are included too .

@Dbug: All changes in source files are properly surrounded by preprocessor directives:

So, Windows build should be intact. And I totally agree with you to not break things but make them better!

@mmu_man: Please, use above repository to download the port and check the diff's against the original sources.
Else, I like your makefile engine - it's nice to parse and reuse *.cmd files. You can check my build system too - I'm interested in your opinion.

So, to summarize I can continue support my port as standalone (it's just part of larger project) but with my all respect to OSDK creators,
I think 'yet another fork' is not good.

I can deal with the #ifdef and try to replace progressively the windows only code by posix friendly ones.
The reason I created the 'common' library was at some point to have all the non portable code abstracted there.

(I can't promise I will not break the linux code from time to time, but when this happens that will not be on purpose.)

And yes, the less forks the better

One important thing should be that version numbers are the same for the various platforms so we can compare the behavior/feature set of programs on the various platforms.

I didn't have time to look much, but at least the history seems quite ugly to me, most of it being a huge deletion and a revert commit right along... That's the kind of things to avoid, and remove before pushing to public repos...
Besides, since it's not yet forked itself you should probably rebase it to drop those...
(hint: use "git rebase -i", move the boggus commit and the revert commit last in history; and rename the revert commit to "squash! ." with git commit --amend", then "git rebase -i --autosquash")

Sure! It's ugly - but in last 2 days I worked from ~7-8 different places and I used git as dropbox .
BitBucket has its own imagination how git works too. So what is in history is not relevant at all.
Anyway, my idea was you just to download from git modified sources, then checkout DF svn and run simple diff
to see what was changed - as result you to agree to merge (or not!) these to DF svn and I'll delete git.
Actually the other approach (keeping git) is good idea too - I can easy cross-build executables for Windows too
and package them together will all additional files as release.