incubator-etch-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Holger Grandy <Holger.Gra...@bmw-carit.de>
Subject RE: C Binding Commit
Date Wed, 09 Jun 2010 13:05:52 GMT
Hi Scott, 

thanks for your answer. ICLAs and CCLAs are now in order, Michael sent his yesterday and is
currently waiting for his account.
In the meantime I checked out https://svn.apache.org/repos/private/committers, which worked
fine, so 
the Apache Account is working.
But I also tried creating a branch "etch-c" from trunk on https://svn.apache.org/repos/asf/incubator/etch/branches,

but this did not work (403 FORBIDDEN). I also tried committing a dummy README file to trunk,
which also 
did not work (also 403). Could you please have a look if there is some extra svn configuration
missing for our new user IDs?

Regarding the other points:
I agree that one full-blown build is nice, but not very handy when the number of dependencies
and build environments increases.
So I would suggest we make a separate Make/Visual Studio based build for the C binding in
the first commit. Later we could
Integrate that into the ant based build. I know that you can call the .net C# compiler from
ant (as the csharp binding does), 
but I am not sure at the moment about the regular VS C compiler. We can have a look at this
later on.

I also agree that we should place dependencies into the etch svn, as long as they are not
too large. We will try that with our
dependencies.

I checked SVN logs, the 1.1.incubating release branch is at the same revision as trunk. So
I would suggest to continue
working with trunk as "trunk" and to merge into the branches if required.

Regarding confusion with C binding implementations: I suggest we create a "etch-c" branch
from trunk, commit our stuff there and
if everyone is happy with it, we merge to trunk. There won't be much confusion, because the
old c binding was not fully functional 
in terms of the Etch compiler and was probably not used a lot. 

Could you have a look at the SVN user stuff?
Thanks a lot, 
Holger & Michael


-----Original Message-----
From: scott comer [mailto:wert1y@mac.com] 
Sent: Mittwoch, 2. Juni 2010 19:01
To: etch-dev@incubator.apache.org
Subject: Re: C Binding Commit

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