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:[email protected]] Sent: Mittwoch, 2. Juni 2010 19:01 To: [email protected] 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-priv...@... mailing list? > will check. > Looking forward to your answers. > > Regards, > Holger and Michael > >
