harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Salikh Zakirov <Salikh.Zaki...@Intel.com>
Subject Re: [drlvm] src/test side-by-side with vm and build?
Date Mon, 14 Aug 2006 21:54:29 GMT
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).

> While we're talking about it, should we consider a fresh layout for

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...

> 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.

> 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.
> 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.

> 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.
> 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.

> 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 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.

P.S. If it was up to me, I would put all sources of each module (DLL) into one directory,
just like

              + vm 
                + *.cpp *.c *.java
              + gc
                + *.cpp
              + jit
                + *.cpp
              + Makefile
              + doc
                + *.html *.txt

P.P.S: do not take it seriously, it is a provocation :)


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