harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm][PATCH/RFC] GNU Make-based build system for DRLVM
Date Wed, 01 Aug 2007 20:05:27 GMT
I also like the idea of using make on C/C++ files.   Thanks Salikh for doing
this!   I will abstain from voting until we know the impact on M3 (or M4).
For example, would Harmony need to still support the existing ant based
system while we migrate?  Is it a big burden for users with windows
laptop to get cygwin tools installed?

On 8/1/07, Gregory Shimansky <gshimansky@gmail.com> wrote:
>
> Xiao-Feng Li wrote:
> > I highly support to have a Makefile based build system. Thanks for the
> > experiments! Only the nice "-j n" can make it a worth try.
>
> +1 I like it very much to use make for building native code. Ant just
> isn't made for it. One disadvantage to using GNU make and shell as
> opposed to nmake used in classlib is that on windows Cygwin environment
> becomes as requirement.
>
> > But I don't suggest to use hard-coded flattened source list in the
> Makefiles.
>
> As long as make files are automatically generated, why not?
>
> > Thanks,
> > xiaofeng
> >
> > On 8/1/07, Salikh Zakirov <salikh.zakirov@gmail.com> wrote:
> >> Hi,
> >>
> >> Recently I've been trying out some massive code reorganizations in
> DRLVM
> >> code in order to improve its modularity (especially concerning
> >> interpreter vs. JIT issue), and that involved mass moving of source
> >> files between components and frequent recompilations, as I am trying
> >> to use resulting compiler and linker errors as a guidance on what else
> >> needs to be done.
> >>
> >> Unfortunately, this kind of exercise proves the current ant-based build
> >> system highly inconvenient, as it has following problems:
> >>
> >> * It neither cleans up stale object files, nor uses object file lists,
> >>   so in case .cpp file was moved, the subsequent rebuild will link the
> >>   stale object file.
> >>
> >>   The obvious workaround is to do a 'build.sh clean', but this is very
> >>   time consuming (~5 min on my machine)
> >>
> >> * Even in case of simple changes to several .cpp files, the compilation
> >>   process takes unacceptably long time. In the extreme, the 'build.sh'
> >>   command with no changes at all takes about 51 seconds on my machine.
> >>
> >> * Ant does not support parallel builds (and my machine is dual-core)
> >>
> >> In order to make the workflow more effcient (so as not to spend too
> much
> >> time on recompilation), I've created a build system using GNU Make from
> >> scratch. It uses a little bit of makefile generation on-the-fly, but
> >> it is relatively simple:
> >> (a) dependencies are tracked using 'makedepend'
> >> (b) individual file compilation rules are generated from source lists
> by
> >> a very simple shell script, which generates output like the following:
> >>
> >>     $ gen-sources-make *.cpp
> >>     OBJECTS :=
> >>     DEPENDS :=
> >>
> >>     OBJECTS := $(OBJ)/a.o
> >>     $(OBJ)/a.o: a.c
> >>             makedepend $(CPPFLAGS) $< > a.d
> >>             $(CC) -c -o $@ $<
> >>
> >>     ... (repeat the above for each source file)
> >>
> >> The end result is included into the makefile. This is needed for two
> >> reasons: (1) flatten object file directory (i.e. source files from a
> >> deep tree will have a flat list of corresponding object files)
> >> (2) to get the list of object files explicitly, in order to prevent
> >> erroneous linking of stale object files.
> >>
> >> The resulting build system has the following advantages over current
> >> ant-based system:
> >>
> >> + No-recompilation run is fast: 3 sec (with hot cache) vs. 51 sec with
> >>   current system
> >> + Stale object files are not linked, even without cleaning
> >> + Parallel make is supported
> >> + The output is nice and clean, without noise
> >> + The configuration files (e.g. vm/em/Makefile) are shorter, and the
> whole
> >>   build process is far easier to understand (to me anyway)
> >>
> >> However, it also has some disadvantages, compared to the ant system
> >> * It only covers building of the native targets (libraries and
> >>   executables), so testing and class/jar building is not covered.
> >>   If this system is accepted, it will probably be called from ant.
> >> * It does not support multiple file compilation with a single compiler
> >>   invocation, and executes compiler once for each source file, which
> >>   may be a real performance problem for some platforms
> >>   (e.g. Windows/Intel compiler). While some hacks to alleviate this
> >>   issue exist for initial compilation, I am not aware of any general
> >>   Make-based solution.
> >>
> >> The result is an attached patch. I do not file a JIRA with patch
> because
> >> it is obviously not (yet) suitable for inclusion.
> >> I would like to hear the comments on the approach and general view on
> >> whether DRLVM needs yet another one build system.
> >>
> >>  build/Makefile               |   58 +++++++++
> >>  build/gen-sources-make       |   55 +++++++++
> >>  build/makerules.inc          |  263
> ++++++++++++++++++++++++++++++++++++++++++
> >>  vm/em/Makefile               |   25 ++++
> >>  vm/gc_cc/Makefile            |   21 ++++
> >>  vm/gc_gen/Makefile           |   19 +++
> >>  vm/interpreter/Makefile      |   26 ++++
> >>  vm/jitrino/Makefile          |   47 ++++++++
> >>  vm/port/Makefile             |   28 +++++
> >>  vm/port/src/encoder/Makefile |   11 ++
> >>  vm/thread/Makefile           |   30 +++++
> >>  vm/thread/jthread/Makefile   |   21 ++++
> >>  vm/vmcore/Makefile           |   62 ++++++++++
> >>  vm/vmi/Makefile              |   22 ++++
> >>  14 files changed, 688 insertions(+), 0 deletions(-)
> >>
> >> In addition to disadvantages mentioned above, it is not complete, and
> >> misses following items, though these can be implemented easily
> >> provided there is enough interest (as the system already does
> everything
> >> I personally need).
> >>
> >> * Configuration is currently written for Linux/ia32/gcc/debug only.
> >>
> >> * Deployment of built targets is currently rather crude (using cp -u)
> >>
> >> * I've just noticed that some changes happened after the I started
> doing this,
> >>   so the Makefiles with source lists will need some update too.
> >>
> >> Comments are welcome.
> >>
> >>
> >
> >
>
>
> --
> Gregory
>
>


-- 
Weldon Washburn

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message