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: [drlvm] src/test side-by-side with vm and build?
Date Tue, 15 Aug 2006 03:29:25 GMT

Salikh Zakirov wrote:
> Geir Magnusson Jr wrote:
>> Yep - I just wanted to park them somewhere as I wanted to close the
>> JIRAs that they came in.  I thought that putting them in a conventional
>> place like 'src/test' would cause a violent allergic reaction in people
>> used to the unique innovation that is the DRLVM layout :)
> Okay, so here you are :)
>> Actually, we need to come up with a real test framework for these, and
>> hopefully pull the other tests out to join them.  
> I agree. 
> Concerning the test framework, we already have at least 3 on hands:
> 1) classic junit
> 2) smoke test runner (1 VM process per test), parse output stream
>    for pass/fail, check the return status. 
>    Ant-based runner is in build system, and shell-based one just as easy to do
> 3) smoke test runner in 1 VM process, tests/smoke/Check.java, 
>    with the same semanics for pass/fail
> Generally, I think we should accept any tests, provided that the tests
> can be run as easy as 'build test' (or 'make check' or whatever that
> can be started by one button press).

Well, yes - in which case we need a framework for the new tests in src/
as they didn't slot in to anything.

>> While we're talking about it, should we consider a fresh layout for
>> DRLVM? 
> Remembering the flamewars when deciding on current one, I would suggest
> that we find a good reason first. A poor peace is better than a good war...

That wasn't our flamewar... :)  That was your flamewar....

>> Maybe we can switch to a make-based build at the same time...
> As far as I can tell from my experience, it is utterly unwise to
> do a build system change and directory layout change at the same time.
> A better approach would be start playing with a new build system
> while majority of the developers stay on the current one.
> And once the new system is in reasonable shape, plan a flag day
> to phase out the old system.

I actually agree, but so we don't have a repeat visit to this little
circle of hell, we should at least consider the build when designing the

>> right now, the layout w/in vm/ is somewhat arbitrary :
> In fact, you just have identified most of the cornerstones of the layout.


>> 1) There is an include directory in parallel with the modules
>>     vm/include/*.h
> This is intentional. These are VM-wide internal interfaces that are
> used to communicate between pluggable VM components (VM Core, GC, JIT).
> This is mostly defines interfaces between DLLs.

I understand that, but it shouldn't be peer with the architectural
modules of the system.  If it's a module, then it's a peer.  if it's a
resource, than make it clear.

>> 2) Some modules have their own include directories  (vm/vmcore/include)
> VM Core module is rather big, so it is split into several subcomponents.
> The vmcore/include directory is for internal interfaces of VM Core, such
> as exceptions. Note, that these interfaces are not exposed to DLL level.
>> 3) Some don't (vm/em)
> Small modules do not require dividing into smaller subcomponents,
> thus do not have any module-wide include directories.

But that would make life so much clearer - you want the module includes,
go into


Patterns and convention are you friends...

>> 4) Some modules have src near the top :
>>    vm/em/src
> In fact, *all* modules are supposed to have src/ subdirectory.
>> 5) Some don't
>>    vm/tests/smoke/
> This is just tests, which are not considered as a module.

Yet a peer to the modules (and the includes...)  Patterns and convention ...

>> 6) Some modules have strange branches by language deep in the path :
>>    vm/vmcore/src/kernel_classes
>>                             /javasrc
>>                             /native
> Again, this is intentional. It is used for separating java sources from c/c++
> sources for modules that have both. Pure-language modules omit it.

Crikey - how can you have anything standardized in the build then?  it's
just arbitrary, so there can be no shared code for each module?  With
patterns, then it's easy to do things, like group includes, sources, etc.

>> What do you think?
> While I do not personally agree with some of the decisions, I think we have
> better things to do than to revise this structure without a good reason.

I can come up with a good reason for everything I've mentioned.

> I think it would be much better to describe the decisions behind the current structure
> somewhere on the web or wiki. I could do it in a few days if someone else doesn't
> volunteer to do it before.

That would be a good starting point, but I think it's the reason the
build is so complicated.  Laying things out in common patterns has
tremendous upside - it's easy to understand where to find things in
module B if you understand module A, for example.

> P.S. If it was up to me, I would put all sources of each module (DLL) into one directory,
> just like
>     drlvm/trunk
>               + vm 
>                 + *.cpp *.c *.java
>               + gc
>                 + *.cpp
>               + jit
>                 + *.cpp
>               + Makefile
>               + doc
>                 + *.html *.txt
> P.P.S: do not take it seriously, it is a provocation :)

I'm hard to provoke :)  I'd suggest, w/o thinking much :

   build/   (where the makefiles/build.xml live)
   target/ (where the generated stuff goes0
   common/   (or maybe src)?

Dunno :)  It's late at night...


> --
> Salikh
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message