Skip to main content

Makefile build target improvements needed - device binary targets and version identification (resend)

2 replies [Last post]
Anonymous

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

Version identification

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!

Gary Adams

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Hinkmond Wong

Gary Adams - Client Systems Group wrote:
> 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
> device installation.
>
> Version identification
>
> 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!

I think the suggested ideas are great. Do you picture new make targets
in the Makefiles to take care of the new build targets?

Like maybe:

make install-device

or

make on-device

Or, will the build targets be part of existing build targets?

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

Gary

Hinkmond Wong wrote:
> Gary Adams - Client Systems Group wrote:
>> 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
>> device installation.
>>
>> Version identification
>>
>> 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!
>
> I think the suggested ideas are great. Do you picture new make
> targets in the Makefiles to take care of the new build targets?
>
> Like maybe:
>
> make install-device
>
> or
>
> make on-device
>
>
> Or, will the build targets be part of existing build targets?
>
>
> Hinkmond
The first step would be to handle the separation of
built artifacts without adding any new build targets.
For instance, if we decide bin and lib directories
are the proper subdirectories for on device deployment,
then isolating build time executables could simply add
a new subdirectory in the build output area. e.g.
maketools/{bin,lib, classes} etc. The second set of artifacts
may be more operational for developers and used after
the build process. e.g. MEKeyTool.jar is used with
feature phoneme products to install certificates
off line, or JadTool.jar for signing jad/jar resources.

The second step could require some new build targets.
This would be the stage where the artifacts are
bundled together into a single installer image.
We know that some platforms this step is hard to fully
automate, because of platform dependent tools that are
used. This step often involves adding legal files
or documentation that comes from other sources
outside the source code repository. Traditionally targets
like "make install" or in our case "make bin_bundle"
would be appropriate.

Gary

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net