Mailing-List: contact etch-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: etch-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: Holger Grandy <Holger.Grandy@bmw-carit.de>
To: "etch-dev@incubator.apache.org" <etch-dev@incubator.apache.org>
Date: Wed, 9 Jun 2010 15:05:52 +0200
Subject: RE: C Binding Commit
Thread-Topic: C Binding Commit
Thread-Index: AcsCdUV8J7RND87RTSifAJ8n+d97PgFWxxtA
Message-ID: <66BD268F973E3544A665E5F503FB38B701F342CA0B@DC01.bmw-carit.intra>
References: <66BD268F973E3544A665E5F503FB38B701D63FC611@DC01.bmw-carit.intra>
 <4C068E30.5090003@mac.com>
In-Reply-To: <4C068E30.5090003@mac.com>
Accept-Language: de-DE
Content-Language: en-US
acceptlanguage: de-DE
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi Scott,=20

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/committe=
rs, which worked fine, so=20
the Apache Account is working.
But I also tried creating a branch "etch-c" from trunk on https://svn.apach=
e.org/repos/asf/incubator/etch/branches,=20
but this did not work (403 FORBIDDEN). I also tried committing a dummy READ=
ME file to trunk, which also=20
did not work (also 403). Could you please have a look if there is some extr=
a 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 numb=
er of dependencies and build environments increases.
So I would suggest we make a separate Make/Visual Studio based build for th=
e 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),=20
but I am not sure at the moment about the regular VS C compiler. We can hav=
e a look at this later on.

I also agree that we should place dependencies into the etch svn, as long a=
s 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 revisi=
on 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 confus=
ion, because the old c binding was not fully functional=20
in terms of the Etch compiler and was probably not used a lot.=20

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


-----Original Message-----
From: scott comer [mailto:wert1y@mac.com]=20
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 Etc=
h project.
>   =20
welcome.
> Now we are looking forward to contributing our implementation, which brin=
gs me directly to the topic: :)
>   =20
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.
>   =20
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 wo=
uld
> 	 suggest that we leave that this way for the initial commit and integrat=
e it into
> 	 the official Etch build in a second step. The C binding can be built fo=
r different
> 	 operating systems (including but not limited to Win32, Linux, OSX), usi=
ng
> 	 different compilers. The suggestion is to check in the Visual Studio pr=
ojects
> 	 and a generic Makefile / Rakefile in the first instance. Afterwards the=
 build system
> 	 can be enhanced and adopted to support different configurations.
>   =20
the current build is using visual studio pieces to build the c# parts,=20
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.=20
it has been suggested that we move all
such stuff into a tools 1) tools dir (top of etch tree) or a separate=20
tools project (substructure underneath etch next
to trunk in the etch tree). i think it makes more sense to have it under=20
the etch tree, as long as it isn't too large.

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

i'm not sure of the current status of trunk. i think there might have=20
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=20
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 illustrate=
s
> 	 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.
>   =20
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 d=
irectory
> 	 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?
>   =20
i guess i'm good with replacing the current c binding with yours. i'm=20
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.=20
the only way to know if you have access is to checkout trunk () and see=20
if you can make a
change, say, to README.txt, make a branch out of it and put your stuff=20
there. when build issues are resolved and we've looked over the branch,=20
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 repos=
itory. 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?
>   =20
will check.
> Looking forward to your answers.
>
> Regards,
> Holger and Michael
>
>   =20