However, in order for this to be productive, I set aside my differences of opinion - and yes, it would be great if I could be considered a safe contributor to the OSDK GitHub repo - there aren't a great deal many changes for me to commit, probably I could've just described the changes in less characters than I've committed to this thread already .. its just more about the workflow of the community that I wish we could improve.
You guys who have done so much already deserve a lot of credit for having gotten us this far without proper version control, that is for sure. . Your temerity under such conditions is worthy of respect.
The issue I have is the SVN <--> GIT bridging work that would need to be done in order to keep different forks of the code in sync. In a community where the majority of the most significant contributors despises modern version control techniques, adding another set of version control technologies seems like a bit of a smell. Maybe its not that significant an amount of effort, lets see. I'll be quite happy to just push stuff up to the GitHub Repo and then let the COPY+ZIP brigade sort it out, as long as there is a place I can point other Git-nerds to, if they want to get involved that way too.
@NekoNoNiaow: FTR, I'm also a Unix geek, almost a greybeard at this point. Me working with Git doesn't prevent me from sharing code with others - its just that, the Git-hating crew are less likely to see the changes unless someone functions as a bridge between the two worlds. The "staging" issue is something we're definitely crossing lines over, but it doesn't really matter - it means one thing in SVN and has a different meaning in Git. I think that where a lot of confusion lies is the fact that, for Git newbies and detractors alike, the idea of having a locally maintained index of the state of the repo is a bit confusing - the thing to remember is that Git tracks everything unless you tell it not to, and any changes that have occurred since the last time it updated its local index, are simply 'staged locally for commit'. Anyway, here is a nice tutorial that I've given to other Git-haters in the past, and it has worked, at least a few times, to make the pain go away - I mean, I've seen new Git users born from having spent an hour just grok'ing this page, anyway: http://rogerdudler.github.io/git-guide/ If its of any use to our little community, lets see. No worries otherwise - those of us who can handle Git, can handle it - and then the SVN/COPY+ZIP brigade will have something to complain about, or not, depending on whether I'm actually doing something valuable to the codebase ..I fail to understand why working on Git prevents you from sharing your changes with others.
And now, for those who have been reading this thread because they want to build OSDK tools on MacOS, here are two very minor changes which have to be made for MacOS:
**Remove fcloseall() call, as we do not have this on MacOS**:
Code: Select all
Index: main/link65/sources/Link65.cpp =================================================================== --- main/link65/sources/Link65.cpp (revision 1473) +++ main/link65/sources/Link65.cpp (working copy) @@ -9,7 +9,7 @@ #include "infos.h" -#define _GNU_SOURCE 1 /* for fcloseall() */ +//#define _GNU_SOURCE 1 /* for fcloseall() */ #include <assert.h> #include <stdio.h> #include <stdlib.h> @@ -536,7 +536,7 @@ #ifndef _POSIX_VERSION flushall(); #endif - fcloseall(); +// fcloseall(); }
**.. and use stdlib.h to gain access to malloc() def's on MacOS:**
Code: Select all
Index: main/pictconv/sources/dither_riemersma.cpp =================================================================== --- main/pictconv/sources/dither_riemersma.cpp (revision 1473) +++ main/pictconv/sources/dither_riemersma.cpp (working copy) @@ -8,7 +8,7 @@ * large memory model. For other compilers, you may have to replace the * calls to malloc() and _ffree() with straight malloc() and free() calls. */ -#include <malloc.h> // for malloc() and _ffree() +#include <stdlib.h> // for malloc() and _ffree() #include <math.h> // for exp() and log() #include <string.h> // memmove()
If someone with more canonical upstream access on SVN would make these changes and verify it doesn't break Linux/Windows builds, then I'm quite content with ignoring the whole Git issue and just moving on to hacking on my Oric project ..