Re: joal extension support
Posted by
notzed on
Feb 12, 2012; 9:16am
URL: https://forum.jogamp.org/joal-extension-support-tp3721871p3736888.html
Sven Gothel wrote
On 02/09/2012 02:24 PM, notzed [via jogamp] wrote:
> No, I don't think so. I find using git about as offensive as it's name, and
> you're pretty lucky I somehow managed to get a clean diff out of it. Every
> time I try something more complex I end up with a broken repository and the
> loss of a few hours of life i'll never get back!
>
Sorry to hear that you don't like it.
My move to git was because of my frustration with svn,
I really messed up with the server side repository using different
client/server svn versions. Sure, hg would have been an alternative
as well - but you have to choose at some point in time.
Well, ok .. so it is and sure I accept your choice,
even though it makes life harder for us - ie. you cannot directly maintain it.
So we continue on a patch base, I would just need the git hash for which
those patches apply to. Since JOAL is rarely updated .. I guess even that
doesn't matter :)
Yeah, well it dates me, but I was an expert on CVS in it's day so I'd prefer that to svn. It's got it's quirks of course ... but at least it knows how to merge (at the file level), and although the tag implementation is utterly dreadful, the way it is intended to work is better than svn too. svn struggles at merging and even svn puts hg to shame in that regard (the hg maintainers don't seem to think merging is that important, at least that's the impression i get from the annotated manual and from trying to use it - thankfully 'diff' and 'patch' saved that day - before I decided to throw it out and never use it again).
I've never been working as the configuration manager of a project with hundreds of developers: so git to me is worthless.
> Sure. I don't think i can come with a neat regex for the constants though
> so it might have to be a common file.
A common header file is just fine, thank you.
Ok. Should I just drop the version of alext.h from openal-soft in, just leave the merge in as I have so far? I will also first check with the openal devs as to whether that loopback device extension is likely to remain for the next release.
I put the top sections of al.h and alc.h into al-types.h and alc-types.h respectively.
I tried adding one, but I can't ant or whatever to use the openal-soft installed in /usr/local so i can only verify that the open function fails.