incubator-etch-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From scott comer <wer...@mac.com>
Subject Re: C Binding Commit
Date Wed, 02 Jun 2010 17:00:32 GMT
hi holger, see comments inline.

all ICLA and CCLA in order?

On 6/2/2010 10:17 AM, Holger Grandy wrote:
> Hi Etch Developers,
>
> first of all thank you a lot for choosing us as new committers in the Etch project.
>    
welcome.
> Now we are looking forward to contributing our implementation, which brings me directly
to the topic: :)
>    
yay!
> Of course we would like to transfer the code which is currently hosted on github into
the Apache
> Etch svn. Afterwards we could close the github repo.
>    
agreed.
> That leads to some issues that we would like to discuss with you:
>
> - Build:
> 	 The C compiler for Etch can be easily integrated into the current Etch compiler build,
> 	 no problem so far. The C binding runtime libraries are currently meant to be built
either
> 	 using Visual Studio, using the GNU toolchain or rake and this build is not integrated
> 	 into the ant based Etch build. Furthermore there are some additional
> 	 dependencies for the C binding (APR, APR-ICONV, CUNIT), which are
> 	 not part of the Etch distribution and have to be downloaded first. I would
> 	 suggest that we leave that this way for the initial commit and integrate it into
> 	 the official Etch build in a second step. The C binding can be built for different
> 	 operating systems (including but not limited to Win32, Linux, OSX), using
> 	 different compilers. The suggestion is to check in the Visual Studio projects
> 	 and a generic Makefile / Rakefile in the first instance. Afterwards the build system
> 	 can be enhanced and adopted to support different configurations.
>    
the current build is using visual studio pieces to build the c# parts, 
with some conditional code included to use mono
when on unix. can you integrate yourself into the ant build like that?

dependences right now come from bits downloaded into a tools directory. 
it has been suggested that we move all
such stuff into a tools 1) tools dir (top of etch tree) or a separate 
tools project (substructure underneath etch next
to trunk in the etch tree). i think it makes more sense to have it under 
the etch tree, as long as it isn't too large.

that brings up a different problem, which is {dependence} x (cross 
product) {os build environment}. having one big
build is nice because all things are available for testing, but in 
practice is rather unwieldly.

i'm not sure of the current status of trunk. i think there might have 
been some work in progress there. 1.1 has branch
made for it, we just need to pump it out. if there is work in progress 
on trunk, it might be best to save it off and start
fresh. i will look into that.

> - Examples:
> 	 The C binding comes with a basic "Hello World" Example which illustrates
> 	 the compatibility between the Java and the C binding. For the future
> 	 it would be nice to see the C binding besides the Java and CSharp
> 	 binding in the "examples" top-level directory. Of course this requires the build
> 	 issue above to be resolved first.
>    
si, agreed. there should be c examples there.
> - Source Code:
> 	 I hope it is ok in general if we replace the content of the binding-c directory
> 	 with the code from github and commit that to the ASF svn.
> 	 We will add the Apache source code header to all the .c/.h files.
> 	 Is there something else we should take care of? Is the Etch svn already set up
> 	 to allow commits from our new apache user IDs?
>    
i guess i'm good with replacing the current c binding with yours. i'm 
worried about confusion, though. how would you
feel about retiring binding-c and calling yours binding-c1?

let's resolve the naming issue above and also the "what is trunk" issue. 
the only way to know if you have access is to checkout trunk () and see 
if you can make a
change, say, to README.txt, make a branch out of it and put your stuff 
there. when build issues are resolved and we've looked over the branch, 
you'll move it
to trunk.

somewhere in there, before commit to trunk, you run RAT on it.

then we can release as 1.2 (after we release 1.1!)

> In a second step we can add the Wireshark plugin source to the Etch repository. But everything
at
> its time :)
>
> What is your opinion on those topics?
>
> Another point: could you please check if our apache user IDs are added to the etch-private@...
mailing list?
>    
will check.
> Looking forward to your answers.
>
> Regards,
> Holger and Michael
>
>    


Mime
View raw message