• file
• revisions
• annotate
• diff
• comparison
• raw

security/nss/coreconf/README@6474c204b198 (annotated)

security/nss/coreconf/README

Wed, 31 Dec 2014 06:09:35 +0100

author

Michael Schloh von Bennewitz <michael@schloh.com>

date

Wed, 31 Dec 2014 06:09:35 +0100

changeset 0

6474c204b198

permissions

-rw-r--r--

Cloned upstream origin tor-browser at tor-browser-31.3.0esr-4.5-1-build1
revision ID fc1c9ff7c1b2defdbc039f12214767608f46423f for hacking purpose.

michael@0	1	OVERVIEW of "ns/coreconf":
michael@0	2
michael@0	3	This README file is an attempt to provide the reader with a simple
michael@0	4	synopsis of the "ns/coreconf" build system which was originally
michael@0	5	fundamentally designed and built to accomodate Netscape's binary
michael@0	6	release model. Wherever possible, an attempt has been made to
michael@0	7	comply with the NSPR 2.0 build system, including mimicing the
michael@0	8	compiler/linker flags, and directory naming structure. The reader
michael@0	9	should keep in mind that the system builds binary releases of
michael@0	10	header files, class files, libraries, and executables on numerous
michael@0	11	flavors of UNIX and Windows operating systems. Unfortunately,
michael@0	12	no serious attempt has ever been made to incorporate an ability to
michael@0	13	generate cross-platform binaries on an Apple MacIntosh platform.
michael@0	14
michael@0	15	Note that this file will not attempt to redefine or document the
michael@0	16	architecture of this system. However, documents on this subject
michael@0	17	are available at the following URL:
michael@0	18
michael@0	19	http://warp/hardcore/prj-ttools/specs/release/index.html
michael@0	20
michael@0	21
michael@0	22
michael@0	23	DEPENDENCIES of "ns/coreconf":
michael@0	24
michael@0	25	The "ns/coreconf" build system requires the specified versions of
michael@0	26	the following platform-dependent tools:
michael@0	27
michael@0	28	UNIX Platforms:
michael@0	29	--------------
michael@0	30	gmake (version 3.74 or later)
michael@0	31	perl 4.0 (NOTE: perl 5.003 or later recommended)
michael@0	32	uname
michael@0	33
michael@0	34	Windows Platforms:
michael@0	35	-----------------
michael@0	36	gmake 3.74 (must use hacked Netscape version)
michael@0	37	shmsdos.exe (contained in Netscape gmake.exe)
michael@0	38	nsinstall.exe (contained in Netscape gmake.exe)
michael@0	39	perl.exe (version 4.0 for everything except testing;
michael@0	40	NOTE: MKS toolkit perl 5.002 is broken)
michael@0	41	perl5.exe (for testing;
michael@0	42	NOTE: perl 5.003 or later recommended;
michael@0	43	MKS toolkit perl 5.002 is broken)
michael@0	44	uname.exe (use nstools version)
michael@0	45
michael@0	46	ENHANCEMENTS to "ns/coreconf":
michael@0	47
michael@0	48	With the advent of Certificate Server 4.0 using the ns/coreconf
michael@0	49	build system, several changes had to be made to enhance
michael@0	50	ns/coreconf support for building Java/JNI classes/programs, as
michael@0	51	well as libraries slated to be released as binaries. While the
michael@0	52	following may not represent an exhaustive list of these changes,
michael@0	53	it does attempt to be at least somewhat comprehensive:
michael@0	54
michael@0	55	(1) During the course of these enhancements, a total of
michael@0	56	four files have been modified, and four new files have
michael@0	57	been added.
michael@0	58
michael@0	59	The following files have been modified:
michael@0	60
michael@0	61	- command.mk: removed old definition of JAR
michael@0	62
michael@0	63	- config.mk: added include statement of new
michael@0	64	"jdk.mk" file
michael@0	65
michael@0	66	- ruleset.mk: allowed the $(MKPROG) variable to be
michael@0	67	overridden by supplying it with a
michael@0	68	default value of $(CC); augmented
michael@0	69	numerous definitions to enhance
michael@0	70	ability of ns/coreconf to produce
michael@0	71	a more robust set of libraries;
michael@0	72	added some JNI definitions; PACKAGE
michael@0	73	definition may be overridden by new
michael@0	74	"jdk.mk" file
michael@0	75
michael@0	76	- rules.mk: separated the compile phase of a
michael@0	77	program from the link phase of a
michael@0	78	program such that a developer can
michael@0	79	now strictly override program linkage
michael@0	80	by simply supplying a $(MKPROG)
michael@0	81	variable; augmented NETLIBDEPTH
michael@0	82	to use CORE_DEPTH but retain backward
michael@0	83	compatibility; added JNI section;
michael@0	84	modified .PRECIOUS rule;
michael@0	85
michael@0	86	The following files have been added:
michael@0	87
michael@0	88	- README: this file; an ASCII-based text
michael@0	89	document used to summarize the
michael@0	90	ns/coreconf build system and
michael@0	91	suitable (paginated) for printing
michael@0	92
michael@0	93	- jdk.mk: a file comprising most (if not all)
michael@0	94	of the default Java related build
michael@0	95	information; the definitions in this
michael@0	96	file are only included if NS_USE_JDK
michael@0	97	has been defined
michael@0	98
michael@0	99	- jniregen.pl: a perl script used to create a
michael@0	100	dependency for when JNI files should
michael@0	101	be regenerated (based upon any change
michael@0	102	to the ".class" file from which the
michael@0	103	".h" file was originally generated)
michael@0	104
michael@0	105	- outofdate.pl: a perl script used to create a
michael@0	106	dependency for when ".class" files
michael@0	107	should be regenerated (based upon
michael@0	108	any change to the ".java" file
michael@0	109	from which the ".class" file was
michael@0	110	originally generated)
michael@0	111
michael@0	112	(2) As stated above, the ns/coreconf build system now separates
michael@0	113	the link phase of a program from its compilation phase.
michael@0	114	While ns/coreconf still works exactly as it used to because
michael@0	115	the $(MKPROG) variable is assigned $(CC) by default, a developer
michael@0	116	may now override this behavior by simply supplying their
michael@0	117	own unique value for $(MKPROG) on every platform. This allows
michael@0	118	a program compiled with $(CC) to link with external libraries
michael@0	119	that may contain "C++" linkage. Before this change, a
michael@0	120	programmer would need to reference their own local copy of
michael@0	121	rules.mk (see the ns/sectools/cmd/pk12util program for
michael@0	122	an example of how this used to be accomplished).
michael@0	123
michael@0	124	(3) Currently, the ns/coreconf build system differs from the
michael@0	125	NSPR 2.0 build system which utilizes an "_s" to denote
michael@0	126	static libraries from import libraries. In fact, the
michael@0	127	ns/coreconf build system adds no prefixes or suffixes to
michael@0	128	distinguish one version of static libraries from another.
michael@0	129	Note that both the ns/coreconf build system as well as the
michael@0	130	NSPR 2.0 build system do nothing to provide a method of
michael@0	131	distinguishing 16-bit from 32-bit static libraries on the
michael@0	132	same machine, either, since:
michael@0	133
michael@0	134	a) this might only provide difficulty during
michael@0	135	development, since static libraries always
michael@0	136	need to be embedded within a program
michael@0	137	(note this is highly unlikely, since libraries
michael@0	138	for different platforms are subdivided via
michael@0	139	a well-known subdirectory structure, and
michael@0	140	a developer may use multiple trees for
michael@0	141	development),
michael@0	142
michael@0	143	b) this maintains backwards compatibility,
michael@0	144	something very important since no legacy
michael@0	145	programs will need to change their link phase, and
michael@0	146
michael@0	147	c) Netscape as a company has dropped any plans
michael@0	148	of future development of 16-bit products.
michael@0	149
michael@0	150	(4) Since several members of the Hardcore Security group did
michael@0	151	not favor NSPR 2.0's solution of adding an "_s" to static
michael@0	152	libraries on Windows platforms as a method to distinguish
michael@0	153	them from their import library cousins, a different solution
michael@0	154	was proposed and has been recently implemented for ns/coreconf:
michael@0	155
michael@0	156	- a 16 has been added as a suffix to both dynamic and
michael@0	157	import libraries built on 16-bit Windows platforms
michael@0	158
michael@0	159	- a 32 has been added as a suffix to both dynamic and
michael@0	160	import libraries built on 32-bit Windows platforms
michael@0	161
michael@0	162	Since the HCL release process currently only contains a
michael@0	163	single instance of building a dynamic library,
michael@0	164	ns/security/lib/fortcrypt/fort12.dll, the impact of this
michael@0	165	change should be relatively small. (Note: HCL was the
michael@0	166	old name of NSS.)
michael@0	167
michael@0	168	It should be noted that although this would additionally
michael@0	169	limit the 8.3 namespace on 16-bit platforms, it is highly
michael@0	170	unlikely that any future development will be performed on
michael@0	171	this platform.
michael@0	172
michael@0	173	(5) The $(LIBRARY_VERSION) tag has been added to all non-static
michael@0	174	libraries created on UNIX operating systems to alleviate
michael@0	175	any future confusion for binary releases which utilize this
michael@0	176	tag. Again, it should be noted that this tag is only
michael@0	177	utilized on non-static libraries, since more than one
michael@0	178	version of the library may need to exist simultaneously
michael@0	179	if multiple products are utilized.
michael@0	180
michael@0	181	Currently, only one HCL released library utilizes this tag:
michael@0	182
michael@0	183	ns/security/lib/fortcrypt/fort12.a
michael@0	184	(e. g. - in this library, the tag has been set to '12')
michael@0	185
michael@0	186	Again, it should be noted that although this would
michael@0	187	additionally limit the 8.3 namespace on 16-bit platforms,
michael@0	188	it is highly unlikely that any future development will be
michael@0	189	performed on this platform.
michael@0	190
michael@0	191	(6) The $(JDK_DEBUG_SUFFIX) extension has been added to all
michael@0	192	library and program names to support debug versions of
michael@0	193	Java programs (e. g. - java_g, javac_g, etc).
michael@0	194
michael@0	195	Once again, it should be noted that although this would
michael@0	196	additionally limit the 8.3 namespace on 16-bit platforms,
michael@0	197	it is highly unlikely that any future Java development
michael@0	198	will be performed on this platform.
michael@0	199
michael@0	200	(7) Most (if not all) default definitions for java have been
michael@0	201	encapsulated within their own file, jdk.mk, which is
michael@0	202	always included by default in ns/coreconf/config.mk.
michael@0	203	However, the definitions within this file are only ever
michael@0	204	activated if NS_USE_JDK has been set to be 1.
michael@0	205
michael@0	206
michael@0	207	(8) Two perl scripts (jniregen.pl and outofdate.pl) have been
michael@0	208	added to the system to foster a more robust development
michael@0	209	environment for composing Java and JNI programs
michael@0	210	utilizing the ns/coreconf build system. Both of these
michael@0	211	perl scripts are related to resolving dependencies which
michael@0	212	can not be accomplished through normal makefile dependencies.
michael@0	213
michael@0	214	(9) This file, README, was created in an attempt to allow
michael@0	215	developers who have familiarity with ns/coreconf a simple
michael@0	216	roadmap for what has changed, as well as a top-level view of
michael@0	217	what comprises ns/coreconf. This file was written in
michael@0	218	ASCII (rather than HTML) primarily to promote simple
michael@0	219	paginated printing.
michael@0	220
michael@0	221	OVERVIEW of "config.mk":
michael@0	222
michael@0	223	This file contains the configuration information necessary to
michael@0	224	build each "Core Components" source module:
michael@0	225
michael@0	226	include file name Purpose
michael@0	227	=================== =======================================
michael@0	228	arch.mk source and release <architecture> tags
michael@0	229
michael@0	230	command.mk default command macros
michael@0	231	(NOTE: may be overridden in $(OS_CONFIG).mk)
michael@0	232
michael@0	233	$(OS_CONFIG).mk <architecture>-specific macros
michael@0	234	(dependent upon <architecture> tags)
michael@0	235
michael@0	236	tree.mk release <tree> tags
michael@0	237	(dependent upon <architecture> tags)
michael@0	238
michael@0	239	module.mk source and release <component> tags
michael@0	240	(NOTE: A component is also called a module
michael@0	241	or a subsystem. This file is dependent upon
michael@0	242	$(MODULE) being defined on the command
michael@0	243	line, as an environment variable, or in
michael@0	244	individual makefiles, or more
michael@0	245	appropriately, manifest.mn)
michael@0	246
michael@0	247	version.mk release <version> tags
michael@0	248	(dependent upon $(MODULE) being defined on
michael@0	249	the command line, as an environment variable,
michael@0	250	or in individual makefiles, or more
michael@0	251	appropriately, manifest.mn)
michael@0	252
michael@0	253	location.mk macros to figure out binary code location
michael@0	254	(dependent upon <platform> tags)
michael@0	255
michael@0	256	source.mk <component>-specific source path
michael@0	257	(dependent upon <user_source_tree>,
michael@0	258	<source_component>, <version>, and
michael@0	259	<platform> tags)
michael@0	260
michael@0	261	headers.mk include switch for support header files
michael@0	262	(dependent upon <tree>, <component>, <version>,
michael@0	263	and <platform> tags)
michael@0	264
michael@0	265	prefix.mk compute program prefixes
michael@0	266
michael@0	267	suffix.mk compute program suffixes
michael@0	268	(dependent upon <architecture> tags)
michael@0	269
michael@0	270	jdk.mk define JDK
michael@0	271	(dependent upon <architecture>,
michael@0	272	<source>, and <suffix> tags)
michael@0	273
michael@0	274	ruleset.mk Master "Core Components" rule set
michael@0	275	(should always be the last file
michael@0	276	included by config.mk)
michael@0	277
michael@0	278
michael@0	279
michael@0	280	OVERVIEW of "rules.mk":
michael@0	281
michael@0	282	The "rules.mk" file consists of four sections. The first section
michael@0	283	contains the "master" build rules for all binary releases. While
michael@0	284	this section can (and should) largely be thought of as "language"
michael@0	285	independent, it does utilize the "perl" scripting language to
michael@0	286	perform both the "import" and "release" of binary modules.
michael@0	287
michael@0	288	The rules which dwell in this section and their purpose:
michael@0	289
michael@0	290
michael@0	291	CATEGORY/rule:: Purpose
michael@0	292	=================== =======================================
michael@0	293
michael@0	294	GENERAL
michael@0	295	-------
michael@0	296	all:: "default" all-encompassing rule which
michael@0	297	performs "export libs program install"
michael@0	298
michael@0	299	export:: recursively copy specified
michael@0	300	cross-platform header files to the
michael@0	301	$(SOURCE_XPHEADERS_DIR) directory;
michael@0	302	recursively copy specified
michael@0	303	machine-dependent header files to the
michael@0	304	$(SOURCE_MDHEADERS_DIR) directory;
michael@0	305	although all rules can be written to
michael@0	306	repetively "chain" into other sections,
michael@0	307	this rule is the most commonly used
michael@0	308	rule to "chain" into other sections
michael@0	309	such as Java providing a simple
michael@0	310	mechanism which allows no need for
michael@0	311	developers to memorize specialized
michael@0	312	rules
michael@0	313
michael@0	314	libs:: recursively build
michael@0	315	static (archival) $(LIBRARY), shared
michael@0	316	(dynamic link) $(SHARED_LIBRARY),
michael@0	317	and/or import $(IMPORT_LIBRARY)
michael@0	318	libraries
michael@0	319
michael@0	320	program:: recursively build $(PROGRAM)
michael@0	321	executable
michael@0	322
michael@0	323	install:: recursively copy all libraries to
michael@0	324	$(SOURCE_LIB_DIR) directory;
michael@0	325	recursively copy all executables to
michael@0	326	$(SOURCE_BIN_DIR) directory
michael@0	327
michael@0	328	clean:: remove all files specified in the
michael@0	329	$(ALL_TRASH) variable
michael@0	330
michael@0	331	clobber:: synonym for "clean::" rule
michael@0	332
michael@0	333	realclean:: remove all files specified by
michael@0	334	$(wildcard *.OBJ), dist, and in
michael@0	335	the $(ALL_TRASH) variable
michael@0	336
michael@0	337	clobber_all:: synonym for "realclean::" rule
michael@0	338
michael@0	339	private_export:: recursively copy specified
michael@0	340	cross-platform header files to the
michael@0	341	$(SOURCE_XPPRIVATE_DIR) directory
michael@0	342
michael@0	343
michael@0	344	IMPORT
michael@0	345	------
michael@0	346	import:: uses perl script to retrieve specified
michael@0	347	VERSION of the binary release from
michael@0	348	$(RELEASE_TREE)
michael@0	349
michael@0	350	RELEASE
michael@0	351	-------
michael@0	352	release_clean:: remove all files from the
michael@0	353	$(SOURCE_RELEASE_PREFIX) directory
michael@0	354
michael@0	355	release:: place specified VERSION of the
michael@0	356	binary release in the appropriate
michael@0	357	$(RELEASE_TREE) directory
michael@0	358
michael@0	359	release_export:: recursively copy specified
michael@0	360	cross-platform header files to the
michael@0	361	$(SOURCE_XPHEADERS_DIR)/include
michael@0	362	directory
michael@0	363
michael@0	364	release_md:: recursively copy all libraries to
michael@0	365	$(SOURCE_RELEASE_PREFIX)/
michael@0	366	$(SOURCE_RELEASE_LIB_DIR) directory;
michael@0	367	recursively copy all executables to
michael@0	368	$(SOURCE_RELEASE_PREFIX)/
michael@0	369	$(SOURCE_RELEASE_BIN_DIR) directory
michael@0	370
michael@0	371	release_jars:: use perl script to package appropriate
michael@0	372	files in the $(XPCLASS_JAR),
michael@0	373	$(XPHEADER_JAR), $(MDHEADER_JAR), and
michael@0	374	$(MDBINARY_JAR) jar files
michael@0	375
michael@0	376	release_cpdistdir:: use perl script to copy the
michael@0	377	$(XPCLASS_JAR), $(XPHEADER_JAR),
michael@0	378	$(MDHEADER_JAR), and $(MDBINARY_JAR)
michael@0	379	jar files to the specified VERSION
michael@0	380	of the $(RELEASE_TREE) directory
michael@0	381
michael@0	382
michael@0	383
michael@0	384	TOOLS and AUTOMATION
michael@0	385	--------------------
michael@0	386	platform:: tool used to display the platform name
michael@0	387	as composed within the "arch.mk" file
michael@0	388
michael@0	389	autobuild:: automation rule used by "Bonsai" and
michael@0	390	"Tinderbox" to automatically generate
michael@0	391	binary releases on various platforms
michael@0	392
michael@0	393	tests:: automation tool used to run the
michael@0	394	"regress" and "reporter" tools
michael@0	395	on various regression test suites
michael@0	396
michael@0	397	The second section of "rules.mk" primarily contains several
michael@0	398	"language" dependent build rules for binary releases. These are
michael@0	399	generally "computed" rules (created on the "fly"), and include
michael@0	400	rules used by "C", "C++", assembly, the preprocessor, perl, and
michael@0	401	the shell.
michael@0	402
michael@0	403	The rules which dwell in this section and their purpose:
michael@0	404
michael@0	405
michael@0	406	CATEGORY/rule:: Purpose
michael@0	407	=================== =============================
michael@0	408
michael@0	409	LIBRARIES
michael@0	410	---------
michael@0	411	$(LIBRARY): build the static library
michael@0	412	specified by the $(LIBRARY)
michael@0	413	variable
michael@0	414
michael@0	415	$(IMPORT_LIBRARY): build the import library
michael@0	416	specified by the
michael@0	417	$(IMPORT_LIBRARY) variable
michael@0	418
michael@0	419	$(SHARED_LIBRARY): build the shared
michael@0	420	(dynamic link) library
michael@0	421	specified by the
michael@0	422	$(SHARED_LIBRARY) variable
michael@0	423
michael@0	424
michael@0	425	PROGRAMS
michael@0	426	--------
michael@0	427	$(PROGRAM): build the binary executable
michael@0	428	specified by the $(PROGRAM)
michael@0	429	rule
michael@0	430
michael@0	431	$(OBJDIR)/
michael@0	432	$(PROG_PREFIX)%.pure: build the "purified" binary
michael@0	433	executable specified by this
michael@0	434	rule
michael@0	435
michael@0	436
michael@0	437	OBJECTS
michael@0	438	-------
michael@0	439	$(OBJDIR)/
michael@0	440	$(PROG_PREFIX)%$(OBJ_SUFFIX): build the object file
michael@0	441	associated with the
michael@0	442	makefile rule dependency:
michael@0	443
michael@0	444	%.c = C file
michael@0	445	%.cpp = C++ file
michael@0	446	%.cc = C++ file
michael@0	447	%.s = assembly file
michael@0	448	%.S = assembly file
michael@0	449
michael@0	450	$(OBJDIR)/
michael@0	451	$(PROG_PREFIX)%: (NOTE: deprecated rule)
michael@0	452	build the object file
michael@0	453	associated with the
michael@0	454	makefile rule dependency:
michael@0	455
michael@0	456	%.cpp = C++ file
michael@0	457
michael@0	458	MISCELLANEOUS
michael@0	459	-------------
michael@0	460	%.i: build the preprocessor file
michael@0	461	associated with the
michael@0	462	makefile rule dependency:
michael@0	463
michael@0	464	%.c = C file
michael@0	465	%.cpp = C++ file
michael@0	466
michael@0	467	%: process the specified file
michael@0	468	using the method associated
michael@0	469	with the makefile rule
michael@0	470	dependency:
michael@0	471
michael@0	472	%.pl = perl script
michael@0	473	%.sh = shell script
michael@0	474
michael@0	475	alltags: tool used to recursively
michael@0	476	create a "ctags"-style
michael@0	477	file for reference
michael@0	478
michael@0	479	The third section of "rules.mk' primarily contains several JAVA
michael@0	480	"language" build rules for binary releases. These are also
michael@0	481	generally "computed" rules (created on the "fly").
michael@0	482
michael@0	483	The rules which dwell in this section and their purpose:
michael@0	484
michael@0	485
michael@0	486	CATEGORY/rule:: Purpose
michael@0	487	=================== =============================
michael@0	488	$(JAVA_DESTPATH):: create directory specified
michael@0	489	as the Java destination path
michael@0	490	for where classes are
michael@0	491	deposited
michael@0	492
michael@0	493	$(JAVA_DESTPATH)/$(PACKAGE):: create directories specified
michael@0	494	within the $(PACKAGE)
michael@0	495	variable
michael@0	496
michael@0	497	$(JMCSRCDIR):: create directory specified
michael@0	498	as the JMC destination path
michael@0	499
michael@0	500	$(JRI_HEADER_CFILES): used to generate/regenerate
michael@0	501	JRI header files for "C"
michael@0	502
michael@0	503	$(JRI_STUB_CFILES): used to generate/regenerate
michael@0	504	JRI stub files for "C"
michael@0	505
michael@0	506	$(JNI_HEADERS): used to generate/regenerate
michael@0	507	JNI header files for "C"
michael@0	508
michael@0	509	The fourth section of "rules.mk" primarily contains miscellaneous
michael@0	510	build rules for binary releases. Many of these rules are here to
michael@0	511	create new subdirectories, manage dependencies, and/or override
michael@0	512	standard gmake "Makefile" rules.
michael@0	513
michael@0	514	The rules which dwell in this section and their purpose:
michael@0	515
michael@0	516
michael@0	517	CATEGORY/rule:: Purpose
michael@0	518	=================== =============================
michael@0	519
michael@0	520	$(PUBLIC_EXPORT_DIR):: create directory used to
michael@0	521	house public "C" header files
michael@0	522
michael@0	523	$(PRIVATE_EXPORT_DIR):: create directory used to
michael@0	524	house private "C" header
michael@0	525	files
michael@0	526
michael@0	527	$(SOURCE_XP_DIR)/
michael@0	528	release/include:: create directory used to
michael@0	529	house "C" header files
michael@0	530	contained in a release
michael@0	531
michael@0	532	$(MKDEPENDENCIES):: for UNIX systems, create
michael@0	533	a directory used to house
michael@0	534	dependencies and utilize
michael@0	535	the $(MKDEPEND) rule to
michael@0	536	create them
michael@0	537
michael@0	538	$(MKDEPEND):: cd to the dependency
michael@0	539	directory and create them
michael@0	540
michael@0	541	depend:: if $(OBJS) exist, perform the
michael@0	542	$(MKDEPEND) rule followed by
michael@0	543	the $(MKDEPENDENCIES) rule
michael@0	544
michael@0	545	dependclean:: remove all files contained
michael@0	546	in the dependency repository
michael@0	547
michael@0	548	.DEFAULT: standard gmake rule
michael@0	549
michael@0	550	.SUFFIXES: standard gmake rule
michael@0	551
michael@0	552	.PRECIOUS: standard gmake rule
michael@0	553
michael@0	554	.PHONY: standard gmake rule
michael@0	555