harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: [porting] FreeBSD
Date Wed, 31 Oct 2007 21:58:46 GMT

On 29 October 2007 at 22:17, "Alexey Varlamov"
<alexey.v.varlamov@gmail.com> wrote:
> Mark,
> 
> Nice to hear about this progress, it's quite inspiring news.
> Looking at the changes, they are simple but scattered through the all
> components. Your ideas or suggestions on improving drlvm portability
> are welcomed. Also, it's interesting to compare build systems of drlvm
> and classlib in this relation - extra inconveniences or advantages of
> each of them?

Since you asked... some initial comments...

1) common_resources/build should probably be renamed
common_resources/make to be more consistent with other components of the
federation build.

I'm not really sure about drlvm, but personally I think using 'build'
directory is confusing since a number of things expect this to be used
to store built classes, etc.  Note: we missed lots of license header
updates because the "standard" Apache script to update the headers
skipped directories called 'build'.

2) I'd get rid of MACHINE_ARCH usage from working_vm/build/build.sh
and working_vm/build/make/build.xml and just use the ant variables.
If people insist on using a 32-bit JRE on a 64-bit machine then they
can override the defaults.

3) After editing the build.xml, working_vm/build/make/build.xml,
working_classlib/make/properties.xml,
common_resources/build/properties.xml, and
working_jdktools/make/properties.xml I did start wishing we had a
common set of properties!  Perhaps we should think about how to
achieve this?

(Aside: similar problems exist for the dependencies but they weren't a
problem for me with respect to porting.  But they are probably just as
important to reconcile.)

4) I don't like working_vm/build/build.sh.  I think we should think
about removing this layer and just calling build.xml directly -
especially when calling it from the federation build ant script.  I
can see what it is trying to do but I still felt it mostly gets in the
way.  It makes assumptions that aren't valid based on variables that
aren't necessary.

4a) Why must I set JAVA_HOME?  Ant doesn't care so long as java is in
my path. And else nothing seems to rely on this variable?

4b) It seems to require me to set ANT_HOME even if ant is in my path
(and in the case of the federation build even if ant is running
build.sh) and on FreeBSD it then fails because freeBSD doesn't have
bin/ant in $ANT_HOME but only in /usr/local.  If I copy /usr/local/bin/ant
to $ANT_HOME/bin it then fails because ant doesn't support --noconfig.

4c) It adds "$PWD/make/tmp/cpptasks/patched.classes" to the classpath
but that doesn't exist in my build.

5) cpptasks ... argh...  I use ccache on my machine and since the
dependency checking from cpptasks is equivalent to doing the
preprocessor step from ccache.  I'm pretty sure compilation would be
faster if ant just called gcc on each file. AFACT, cpptasks
effectively does the preprocessor step twice.  If we want dependencies
to work properly (and I do) we should just use gcc -MF where supported
to generate them as a by-product of a compile.  ("gcc -MF" is supported by
ccache).

(I'm going to look at Salikh's patches in HARMONY-4640.)

6) I had to replace code doing readlink("/proc/self/exe") in classlib
and 3 (?) times in DRLVM.  This really should be implemented in one
place.

7) I still need to fix the get_all_native_modules code.  Doing the
exact equivalent of get_all_native_modules looks quite difficult on
FreeBSD but at first glance I don't see any uses that need *all* the
modules since most are really looking for the file containing a specific
address.  I suspect that this code would be much more efficient (and
more maintainable) if it just used dladdr lookups instead on linux/posix
platforms.

8) Has anyone tried to get the apr patches applied to apr?  I'm not sure
I understand the apr_arch_thread_cond.h one but the others all seem
pretty reasonable.

9) Quite a few bits of code look like:

  #ifdef _WIN32
  #endif
  #ifdef __linux__
  #endif

Porting is easier if these are changed to:

  #if defined(_WIN32)
  #elif defined(__linux__)
  #else
  #error need to provide ... for this platform
  #endif

using if defined(...) makes it easier to add new platforms.  In some
case, for example when defining path separators it probably make
sense to do:

  #if defined(_WIN32)
  #else
  ... defines for typical unix
  #endif

In the worst case, there are pairs of files with '#if WIN32' around all
of the code in one file and '#if LINUX' around all of code in the other
one.

10) ${common.includes} is in the include path for compiles but doesn't
exist.

11) When using unix system calls, it is a good idea to include the
header files that the man pages describe in the SYNOPSIS.  For instance,
malloc comes from stdlib.h not malloc.h, etc.  Doing this correctly
saves having to fix it on more strict platforms.

...

More when I have time.

Regards,
 Mark.



Mime
View raw message