Gnu make conversion and consolidation Engineering Specification

RFE: 4549083

Author: Steven Katz
Date: 13 May 2002


1 Project Description

1.1 Overview

As of this writing the build system for the Plugin consists of three separate schemes.  In no particular order, the general UNIX scheme, the general Windows scheme and the scheme for building the HTML Converter.

The general UNIX scheme uses a single Makefile that contains the build instructions for each target and includes additional Makefile that contain file information.  The Makefiles in this scheme are written for GNU Make.

The general Windows scheme uses multiple Makefiles.  Each one of which builds a sub directory of the source for the Windows plugin.  Recursive calls are made from a top level Makefile to build each of the targets known to the sub Makefiles.  The Makefile in this scheme are written for nmake.

The HTML Converter uses a single Makefile and includes additional Makefiles like the general UNIX scheme.  In this scheme however the Makefile itself determines which platform it is building for and acts appropriately.  The Makefile in this scheme is written for GNU make.

It should be intuitively obvious that having three different schemes for building the Plugin is not a desirable situation.  As such it is the intent of this project to reduce this complexity down to a single method of organizing the build instructions for different targets.  Also this project will standardize on a single make system.

1.2 Project Dependencies

1.3 OS and Browser Compatibility and Interpretability

The solution offered must work on all OS's for which the plugin has deliverables.

1.4 Performance and Scalability

1.5 Security

1.6 Internationalization (I18N) / Localization (L10N)

1.7 Packaging

1.8 Usability

1.9 Quality

1.9.1 Unit or Functional Tests to be Delivered

1.9.2 Additional Testing Notes



2 Technical Description

2.1 Architecture

It is my opinion that the best course of action we can take is to adopt a scheme that incorporates elements from each of those mentioned above.  As such we should:

1) Standardize on GNU make.
This is the build mechanism used by the rest of Java.

2) Use recursive make to build sub-parts of the Plugin.
It should be possible to decompose the plugin into it's actual deliverables.  Each of these deliverables should have it's own sub directory that contains it's own  Makefile.  Makefiles that live in sub directories should be completely self contained.  That is, they should not depend on inheriting variable values from the Makefile that might call them.  The JRE provides a set of includable Makefiles that define common values.  These should be included by each sub directory Makefile.  Additionally, Plugin specific variable should live in includable Makefiles controlled by the Plugin team.

Deliverables should be thought of as file system artifacts such as scripts, shared libraries, etc.  Deliverables should be grouped together by upper level targets to  facilitate building.  For example, there would be an upper level target that builds the Netscape 4 plugin called ns4.  This target would depend on each of the deliverables that would actually compose the complete Netscape 4 plugin, such as the Control Panel, the libjavaplugin.so file, etc.  For some deliverables it might make sense to combine them into a single sub directory Makefile.  For example, the Control Panel is actually composed of several file system artifacts, but since no other part of the plugin depends on them they need not be separated out.  The counter example to this would be something like the java_vm command.  It is needed by both the UNIX Netscape 4 and 6 plugins so should be in it's own sub directory Makefile.

3) Separate out analogous deliverables by including different Makefiles in a single controling Makefile, not by introducing additional sub directory Makefiles.  By this, it is meant that if two deliverable perform the same conceptual functions a single Makefile should build both by including different specific Makefiles.  For example, both the Windows and UNIX plugins build a shared object that is loaded into Netscape 4.  Instead of having two separate sub directories, one that builds the UNIX version and one that builds the Windows version.  There should be a single sub directory Makefile that includes into itself a platform specific Makefile that has the proper commands and targets for the given platform.  In the long run, this will make it easier to combine together source that does essentially the same thing but for different platforms.  It also means a developer will only have to look in one place to figure out the things that are similar between the platforms.

4) When applicable, the Makefiles will build debug as well as optimized versions of all deliverable.  This will be done internal to the Makefile, not as a result of two recursive calls.

With this in mind, here is a partial list of targets and deliverables:

all:  all the deliverables
ns4: all the deliverables needed to have a complete plugin for Netscape 4
ns6: all the deliverables needed to have a complete plugin for Netscape 6
ie: all the deliverables needed to have a complete plugin for IE

libjavaplugin.so:
javaplugin.so:
np*:
controlpanel:
htmlconverter:
javaplugin.jar:
java_vm:

The standard house keeping targets (clobber etc.) will be implemented where appropriate by each sub directory Makefile

Targets for installation will be handled by both the upper level Makefile and the sub directory Makefiles as needed.

2.2 Exported Interfaces/API

2.3 Imported Interfaces/API

2.4 User Interface



3 Marketing

3.1 Justification

3.2 Customer Request

3.3 Competitive Analysis



4 Management and Planning

4.1 Scope/Priority

4.2 Target Release

4.3 Resources

4.3.1 Development

4.3.2 Quality Assurance/Testing

4.3.3 Documentation

4.3.4 Technical Support

4.3.4 Special Hardware/Software

4.4 Schedule

Start Date End Date Activity Owner Status
         
         
Complete Started Not Started Difficulties Trouble


Appendices (as needed, suggestions below)

A. Background Information

B. Interface Specifications

C. Notes and Additional Details

D. Miscellaneous

E. Tracking

E.1 Final Webrev

E.2 Bugtraq
Bugid P S Subcategory Type Engineer Synopsis
 4549083            



Revision History

Date Version Author Description
 05/13/02  0.1  smk Initial version