[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Building SOPE with GNUstep
From: |
David Ayers |
Subject: |
Re: Building SOPE with GNUstep |
Date: |
Fri, 12 Mar 2004 19:20:40 +0100 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 |
Helge Hess wrote:
On 05.03.2004, at 11:11, David Ayers wrote:
I use plain CVS versions of -make, -base and SOPE (I do not have
Cocoa) but the problems I encountered were make file setup and libxml
configuration dependent. I'll update again and attach the output.
I think I used gstep-make 1.8 on Cocoa, not sure (current is 1.9+ I
guess). Its unfortunate that gstep-make API changes do not lead to a new
major revision :-|
I'm pretty confident that my issues have little to do with -make API
changes. I believe it has to do with finding libxml2 (which is
installed in /usr/local on my system) and the non-gnustep-make make
rules in the top hierarchy. But maybe I'll have time to look closer
next week.
I can't comment on the WO4.5 API compatibility. (I do notice though
that you consistently omit the version when talking about
compatibility, which makes me wonder whether it may be 4.0 or even 3.x
which you may be referring to, so maybe you can clarify.)
I'm referring to WO 4.5. The only major changes where done between WO
2.0 and WO 3.0 as you probably know. We are also adding some 5.2
extensions (like streaming) which may be relevant as well though never
available in ObjC WO.
Thanks for clarifying, I guess we a have different perception on what
constitutes a major change. But let's leave it at that.
Consider SOPE. This will make you jump 10 steps ahead (AGAIN: not
because gstep-web developers are less capable but just because way
more time went into SOPE!). This helps *everyone*. Its "only" hard
because you need to abandon code.
This is dependent of on
- portability / interoperability with GNUstep (i.e. base) on the
platforms supported by GNUstep
Of course it needs to be fully ported and working on GNUstep
(make/base[/GDL2]). This is an obvious precondition before SOPE makes
sense in a GNUstep context.
There is no question on that.
- FSF copyright assignment
I guess we cannot solve that.
To bad... not that we necessarily need all of SOPE to be copyright
assigned, it would already be great if you could copyright assign
certain fragments that we may identify as being helpful for GSWeb. OTOH
it shouldn't be impossible to learn from your implementation and do it
from scratch in a GSWeb context.
- formal coding issues.
Not sure what you mean by that.
Would only be relevant for full copyright assignment of the project.
As SOPE is LGPL and you don't see yourself capable/willing of
assigning the copyright to the FSF, I'm also fine with people using
SOPE instead of GSWeb if they feel more comfortable with it.
Personally, I prefer to complete the 'official' GNUstep package.
Since the 'official' GNUstep also uses non-FSF assigned code thats a
pretty weird limitation.
Well if you mean GSANTLR (which I guess is derived from NGAntlr), then
yes. But removing that dependency was on my TODO list nearly from day
one. But that wasn't because of the copyright issue, as I didn't even
realize it then, but because of technical issues. It's been superseded
by the libxml2 wrt template parsing. It's still currently used for
gswd(wod) parsing, but that's pretty overkill for those kind of files
and not really worth the extra dependency. (Another annoying
implementation detail was the exception driven implementation that
raised every time it finished parsing a file, which I think was there to
mimic some java like file io handling, but I've replaced that since.)
OTOH, it's working, and ANTLR template parser was available and could be
activated by it's users. I also didn't realize the surprisingly small
amount of projects that depend on GSWeb. I thought their might be some
out there that may still be using that parser.
So if we can replace the xml based parser with a handwritten template
parser, I'd like to look into replacing the gswd(wod) parser also an get
rid of the dependency on GSANTLR and ANTLR itself.
But anyway, not going to argue on that, if you consider a FSF assignment
not even valid in Europe nor implemented in CVS more important than we
proably won't find a solution.
I have yet to see any verifiable statement that an FSF assignment is
invalid. Back when I first learned about the FLA I posted on the FLA
list asking about the situation and whether it would be advisable that I
sign corresponding papers. I was told that my FSF copyright assignments
where absolutely sufficient. IANAL (but my situation may be special) so
may I ask you to point me to an official site of authority in this
matter that can confirm that the copyright assignment of a EU / German
citizen is an illegal act? OTOH, you have made it painfully clear that
the legal issue of copyright assignment is irrelevant for you and this
is personal/company decision that you won't contribute to the FSF.
We'll do. GDL2 is probably the next thing to make people happy asking
for EOF/MacOSX support. Its great to hear that you want to work with
us on this, so finally we have anothing thing to share.
Not quite sure what you're insinuating, but yes, you, and everyone
else in the world (baring and legal export restrictions :-) ) is
welcome to use this code (GSWeb and GDL2) under the corresponding
license and report issues they find which we (and I'm sure this
includes Manuel) will try to address.
Well, this sounds like GDL2 is a closed project. Of course we do fixes
on our own and either get them incorporated (of course better) or fork
(less than ideal).
When I was referring to Manuel, I meant to say that he's just as willing
to help as I am. GDL2 is not a closed projects. We invite anyone to
contribute code. We have a single requirement: FSF copyright
assignment. If you're not willing to contribute, then we'll just have
to live with that.
But when it comes to building SOPE on GNUstep, understand that I have
other priorities.
I already wrote several times that no one is expecting that from you. A
cooperation is a two way thing. Of course OGo project members will work
to improve GNUstep related things as well as to port OGo libraries to
current recent things in case something is received in return.
In the actual case of the GS port, this is already taken on by several
volunteers.
The goal of a GNUstep/OGo is to avoid duplicate coding of the same
stuff. That this implies some prior work on streamlining available
things on both sides is somewhat obvious.
If you priority is to reimplement already existing things, I'm fine with
that. After all cooperation was just a suggestion.
My priority lies with the gnustep implementations. If others are
willing to contribute code, that is great. If others want to use ours,
that's fine under the LGPL. The point is that you seem to be unwilling
to contribute code. You'd prefer a non FSF project with copyright
holders scattered around the world. That's your prerogative. And you
may very well find people that support this. That's just fine. I've
decided that I'm contributing to FSF assigned code.
IOW: if you can look at my log and tell me rather precisely what I
forgot or have to tweak, I may try another build in a couple of days,
but I can't investigate.
Just wait until the port is finished, we'll drop a line when its done.
As mentioned the goal is to reuse the gstep-base library for the
official Debian packages of OGo, so there is some focus on that.
OK. Good luck.
Prior trying to build, you should check:
http://www.opengroupware.org/en/projects/gnustep/
on the status.
Thanks for the pointer but I don't think I'm having those issues (yet :-) )
Cheers,
David
Re[2]: [GSWHackers] Re: OGo/GNUstep cooperation Re: Re[2]: Frameworks integration, Manuel Guesdon, 2004/03/05
Re[2]: Re: OGo/GNUstep cooperation Re: Re[2]: Frameworks integration, Manuel Guesdon, 2004/03/08