Re: [Cgdb-devel] C ADT library

[Ronald Landheer-C. <ro...@la...>]

Bob Rossi wrote:

>On Thu, Mar 04, 2004 at 09:25:17PM +0100, Ronald Landheer-Cieslak wrote:
>  
>
>>Bob Rossi wrote:
>>
>>    
>>
>>>Hi,
>>>
>>>I am leaning towards option 3. Glib is widely used and comes with a
>>>testsuite. I found that CGDB could have support for these ADT's 
>>>1. garray
>>>2. ghash 
>>>3. glist
>>>4. gqueue
>>>5. gtree
>>>6. gstring ?
>>>7. gcompletion?, 
>>>
>>>These are 5-7 of the 49+ files that are delivered with glib. It would
>>>take about 1 week to abstract these files out of Glib, and then CGDB
>>>would have access to these ADT's. If we go down this route, we area also
>>>left with another question. Should we update the files when Glib
>>>changes? or should we check them in with different names and totally
>>>diverge from Glib?
>>>
>>>I would appreciate a response, since I can not continue development on
>>>CGDB until this issue is resolved.
>>>
>>>
>>>      
>>>
>>If you're looking for a widely-used already-existing C implementation of 
>>a set of ADTs (and only ADTs) that will run OOTB on every platform 
>>supported by GDB, I'm afraid you might be asking a bit too much. It is 
>>what libcontain aims to become (other than being "blindingly fast", 
>>thread-safe for all operations, etc.) but that is precisely because such 
>>a library - to my knowledge, doesn't exist yet.
>>    
>>
>
>Are you interested in starting libcontain with the data structures from
>Glib? But changing the interface, typedef's, ... so that you can change
>the implementation later to whatever you want.
>
>I would be interested in porting away the code and committing them to
>libcontain.
>
>CGDB, could then merge libcontain into it every time some nice new
>improvement came along.  That way, you would get a head start on the
>data structures you need, and CGDB could use libcontain. 
>
>It could be a marvelous relationship :)
>
>  
>
>>My personal preferences and pet projects aside, glib seems to be a very 
>>good choice, provided it really is very portable. If you do choose to go 
>>that way, please just make sure that the parts of glib you choose are 
>>cleanly cut out of glib and that you don't get left with any instable 
>>code that would have worked if glib had been there. Other than that, 
>>*please* make sure you can revert back to the state before integration 
>>of glib code (e.g. by doing it on a branch first and letting us porters 
>>have a go at it before merging it into HEAD).
>>    
>>
>
>Ok, I will add the new ADT classes to a branch.
>
>  
>
>>As far as keeping up with glib is concerned - I wouldn't bother: be on 
>>the lookout for bugs that are found in their implementation, but don't 
>>bother taking on new features they might add - you probably won't need 
>>them anyway.
>>    
>>
>
>You are right.
>I don't ever plan on keeping up with Glib after the port. 
>  
>
That would place libcontain under GNU LGPL (it is under a BSD-GPL double 
license right now) but it would definitely get libcontain a lot further 
on its road.
(... thinking ...)

yeah, why not :)

I'll have to isolate the glib code from the rest of my code pretty 
clearly, though, so I don't end up re-licensing Jail-ust, but LGPL is 
not as virulent as GPL so it should be OK.

I'll get right on it.

rlc