Makefile build target improvements needed - device binary targets and version identification (resend)
During the MIDP on CDC development effort we have had to merge
separate styles of makefiles as we combined build targets from
separate development teams. Now as we step back and begin to formulate
deployment bundles we are running into some of those inconsistencies
on a regular basis. Before attempting to fix the problems in
our specific area, I'd like to start a dialog with other project
owners to make sure we can solve the problems in a consistent
manner for all the Java ME deliverables.
First a couple of obvious problems we need to address.
Device versus Server deliverables
When building MIDP a variety of build targets result in
files in the bin// directory. Some of these
are intended to be deployed on the device, but others are
only used from an off device location. Examples would be the
tools for managing skin creation or romization.
Similarly in the building of JSROP libraries lib/jsrxxx.jar
files are created. For a ROMized build these files are not used
on the device at runtime. They are created primarily as an
intermediate (temporary) file til the code is ROMized. They are
also useful for static signature test verification in
most TCK test suites.
I'd like to propose that we separate out in the build output
directory we separate the on device and off device build targets.
This will make easier creation of zip or CAB files for
Once a binary has been built there is not currently an
easy way to identify the components or revisions of
components used to construct that binary. For CVM there
has been discussions of how to make the "-version"
command line more encompassing to clearly identify the
platform. For MIDP/CLDC deployments where no command line is
available there have been talks historically about
providing the information in an About box, or with in some
standard set of properties of *.h header file.
Ideally when a bug is reported against a particular
build, the standard information about revisions of components
would allow another developer to quickly reconstruct
the failed configuration. Versions of tools as well as
versions of sources used are both critical information.
Rather than just dictate a solution, I'd like to engage the community
to identify similar items we could address as we open up the makefiles
for improvements. We'd like to take best of breed solutions and
apply them to both feature and advanced phoneme projects over time
as schedules permit.
All feedback appreciated!
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com