forum.defence-force.org

Hi,

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

http://www.ibm.com/developerworks/opens ... ecl-vscdt/

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.

I know mmu_man is working on something.

I'm working too on a "fork" of osdk for non window platform (Macos X, Linux, Unices...) the process is not really complicated, but really time consuming.. (and it will not binded to a specific IDE )

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.

For more info see attached Readme.linux file.

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.

Indeed, I already did most of the preliminary work in svn (fixing all the ugly non-POSIX calls) but didn't have time to finish...
I'd like to have a look at the diff first.

As for building programs, I already have a fully working makefile engine template in svn, just not integrated with OSDK yet:
http://miniserve.defence-force.org/svn/ ... le-engine/

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.

All comments and opinions are welcome!

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.

Today I added: bin2c, dxa, file65, ldo65, reloc65, tap2wav, txt2bas, 4k8totap, 4k8towav, wav2tap, wavclean.
No problems with compilation at all.

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.

iss wrote:Today I added: bin2c, dxa, file65, ldo65, reloc65, tap2wav, txt2bas, 4k8totap, 4k8towav, wav2tap, wavclean.
No problems with compilation at all.

What are bin2c, dxa, file65, ldo65 and reloc65? That seems like parts of CC65?

Are you planning to bring these to the osdk?

bin2c - well known utility to convert binary file to c - source code.
dxa (disassembler), file65, ldo65 and reloc65 are parts of XA.

iss wrote:bin2c - well known utility to convert binary file to c - source code.
dxa (disassembler), file65, ldo65 and reloc65 are parts of XA.

Then they must be part of the new XA development, not from the branch we started from 10 years ago - they are different code bases, and most probably not 100% compatible anymore.

Why do you want to add bin2c? We have bin2txt already which does exactly that (plus assembler) format compatible with XA syntax.

yep, you are right - no need of duplicates.