harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: classlib/trunk repository structure
Date Fri, 10 Feb 2006 15:16:56 GMT


Alexey Petrenko wrote:
> Isn't it a good time to normalize classlib/trunk repository structure
> and update "Apache Harmony Contribution Policy" document
> (http://incubator.apache.org/harmony/contribution_policy.html) while
> we got small number of modules?

I think that given the fact that everyone is short on cycles as well as 
certainty, I'd like to see us test some alternative approaches before we 
decide on the One Tru Way and start moving things.

As for the policy doc, why?  To match component names to policy 
documentation?


> 
> Here is what I mean...
> 1. There is classlib/trunk/native-src directory. README says:
> "native-src contains native source files only". So it looks like
> correct place for ALL the native sources.
> If so why we got native sources in
> classlib/trunk/modules/security2/src/linux/other/? 

I'm not at all convinced that the natives should be separate from the 
modules.

> And why we got
> additional java subdirectory in every main directory?

It's the language the stuff below is written in.

> I think that we should store native sources under modules directory
> with all other module sources. modules/modulename/src/main/native
> looks like a good place for this. It will make looking for module
> sources much easier.

yes - and I'm sure it's "on the list"

> 
> 2. It's not clear where the system specific java sources should be stored.
> I think modules/modulename/src/linux and
> modules/modulename/src/windows will be a good place.

Mmmmm. We talked about this before.... I think the thought was to group 
the natives for a module together under something to prevent src/ having 
too many children...

I'll go look back in archives.

> 
> 3. It's not clear what should be placed in modules/modulename/src/main
> directory. Main sources? What is main sources? May be it's system
> independent sources? If so may be common it better name for this
> directory?

It's to distinguish from "test"

> 
> So I suggest the following structure for sources:
> classlib/trunk/modules/modulename/src/ - all the sources for
> "modulename" are here.
> classlib/trunk/modules/modulename/src/common - all the system
> independent sources are here
> classlib/trunk/modules/modulename/src/common/java - common java sources
> classlib/trunk/modules/modulename/src/common/native - common native sources
> classlib/trunk/modules/modulename/src/linux/java - linux specific java sources
> classlib/trunk/modules/modulename/src/linux/native - linux specific
> native sources
> classlib/trunk/modules/modulename/src/windows/java - windows specific
> java sources
> classlib/trunk/modules/modulename/src/windows/native - windows
> specific native sources
> 

I think this is like what we came up with on the list earlier.  I had a 
few concerns :

1) That when working in common IDEs, that it was convenient to work with.

2) That build scripts were parametized and simple - so that you could 
specify a platform, and it would build for that platform. w/o lots of 
special cases or duplication in the build scripts.


> The last question is platform specific sources (IA32, IA64 and so
> on)... We can easily put them under windows/IA32 or so...

That's where I fear irregularity, and where this gets harder.  Because 
there are going to be some platforms where there is divisions (like 
windows - ia32, ia64) and some not (say, OSX, although now they have PPC 
and Intel)

So what happens with platform common code?

windows/common
        /ia32
        /ia64

?

As long as the build system and test system is easily parameterized for 
maintainabliity, I'm happy w/ something like this.


> Any thoughts?

> 
> When some decision will be agreed or current structure become clear I
> will prepare patch for "Contribution Policy"... If nobody mind.

Hang on.  before you do that, care to explain a bit why?
> 
> --
> Alexey A. Petrenko
> Intel Middleware Products Division
> 
> 

Mime
View raw message