Create foo/Makefile.am
(3). This is the main task. Let's
simplify and say that foo
should yield to one
library, generate one stand alone binary for testing
purposes. For your convenience, a skeleton can be downloaded. In the skeleton
file, things to be replaced are between []
's.
You start by telling automake the libraries, standalone
executables and jarfiles that should be created; along with the
flags gcj should be using building things natively:
## Process this file with automake to produce Makefile.in.
AUTOMAKE_OPTIONS = foreign
## ################################################################
##
## What gets installed, and where.
##
lib_LTLIBRARIES = lib-package-that-foo-defines.la
check_PROGRAMS = test_standalone_executable_name
JARFILE = package-that-foo-defines.jar
BUILT_SOURCES = $(JARFILE)
data_DATA = $(JARFILE)
## ################################################################
##
## Compilers and compilation flags.
##
AM_GCJFLAGS = -fassume-compiled -fCLASSPATH=$(srcdir)/upstream/src
AM_GCJFLAGS
could contains other flags, like
--encoding=...
or -fjni
, etc... If
foo
contains native parts, you might have to define
AM_CFLAGS
.
package-that-foo-defines
means that for example if foo
defines and implement
org.gnu.foo
, you would write it org-gnu-foo
(it's an automake convention.) lib_LTLIBRARIES
(and
subsequently JARFILE
) could contain more than one
entry.
Then you need to explain what are the files that you need to
consider in order to build the components. There's one entry per
entry found in lib_LTLIBRARIES
:
## ################################################################
##
## What libraries need in order to be built
##
lib_package_that_foo_defines_la_la_SOURCE = \
./upstream/src/<package>/<that>/<foo>/<defines/<file>.java \
./upstream/src/<package>/<that>/<foo>/<defines/<other_file>.java \
...
package_that_foo_defines
means that for example if
foo
defines and implement org.gnu.foo
, you
would write it org_gnu_foo
(it's an automake convention.)
If package_that_foo_defines
requires other libraries
to link properly, then it should be expressed as:
lib_package_that_foo_defines_la_LIBADD = ...
How would you specify how to build the stand alone
test executable? You would add the following section:
## ################################################################
##
## What (test) standalone executables need in order to be build.
##
test_standalone_executable_name_SOURCES = ...
test_standalone_executable_name_LDFLAGS = --main=<access_to_main> ...
test_standalone_executable_name_LDADD = -L. -l-package-that-foo-defines
The last thing you have to specify is how the jarfile gets
created. It's not super clean yet, maybe future features in
automake will simplify things (and maybe they do already:)
## ################################################################
##
## Class file business
##
CLASSFILES = $(lib_package_that_foo_defines_la_SOURCES:.java=.class)
%.class: %.java
$(GCJ) -C <other_flags> -d upstream/src $<
<other_flags>
could be for example
--encoding=UTF-8
. You could introduce a new
variable in order to share as much flags as possible with
AM_GCJFLAGS
. The there's a rule to add on how to
generate the jarfile:
$(JARFILE): $(CLASSFILES)
(cd upstream/src; for x in `find ./ -name \*.class`; do $(GCJH) `echo $$x | sed "s/\.\///g" | sed "s/.class//g"`; done;)
(cd upstream/src; jar cf ../../$@ `find ./ -name \*.class`)
There are a couple of missing things (notably
EXTRA_DIST
), but with this you should be able to
see a build start. You can also read other Makefile.am
files for inspirations: gnu.readline/Makefile.am
is a good
example -- because it's small, handles JNI files, the creation of test
executable and jar files.