Alcatel-Lucent nmake Product Builder

Release lu3.6 for UWIN

Release Date: April 2004

For an overview see the nmake for UWIN Overview page.

Download Software

Release Notes

Table of Contents

• Introduction
• Requirements
• Compatibility
• Features
• Change Log
• Limitations

Introduction

nmake for UWIN allows the use of nmake on the Windows® 2000 operating system.

Requirements

UWIN release 3.1 is required in order to use nmake for UWIN. The user is responsible for obtaining and installing UWIN. nmake uses the UWIN cpp and UWIN cc wrapper. Some UWIN packages may not have these components.

Hardware requirements

• Total memory requirements vary based on the size and complexity of the build, specific build tools used, number of concurrent builds/compiles, and other factors; typically 64MB should be adequate on all platforms although use of the product with less memory is possible.
• Product requires maximum 25MB disk space including user manuals. Actual disk requirements may be less depending on platform.
• nmake will run on any CPU capable of supporting the host OS and platform environment; there are no special CPU requirements.

Compatibility

1. Supported Platforms:
   • UWIN 3.1 on Windows 2000 with NTFS
   • UWIN 3.1 on Windows 2000 with FAT32
2. Supported Compilers:
   • MS VC++ 6.0 using the UWIN cc wrapper
3. Makefiles: A primary goal of this release is to maintain compatibility with existing nmake makefiles. Makefiles written in a portable manner should function essentially unchanged on UWIN. However, this does not guarantee that the products being built will compile or run properly on UWIN or WIN32 without changes.
4. Pathnames: nmake uses UWIN POSIX-style paths. The only valid path separator is slash ('/'). Colon (':') and back-slash ('\') are not allowed in pathnames in makefiles. Pathnames must be valid on hosting file systems. FAT and NTFS file systems do not allow some characters in pathnames, such as "*<>|.

Features

The following new features are introduced in this release to support the Windows 2000 platform.

1. Support for building win32 DLL shared libraries
   The :LIBRARY: and :: operators can build both static (.a) and dynamic (.dll/.lib) libraries. The generated .a and .lib files are installed in LIBDIR by default. Following standard practice on win32 platforms, the generated .dll files are installed in BINDIR. When building dynamic libraries the PIC compiler flag should be included (CCFLAGS+=$$(CC.PIC)). The following examples show the assertions that can be used to build libraries.
   • abc :LIBRARY: abc.c
     Produces a static library (libabc.a) by default, or both static and dynamic libraries (libabc.a, abc.dll, abc.lib) when :ALL: or the install common action is asserted.
   • libabc.a :: abc.c
     Produces a static library (libabc.a).
   • abc.dll :: abc.c
     Produces the run-time dll library (abc.dll) and corresponding compile-time lib file (abc.lib). A static library (libabc.a) is also generated and used for the generation of the dynamic library files.
   • abc.lib :: abc.c
     Equivalent to the abc.dll target above.
   The :LIBRARY: operator provides target abstraction for platform portability. When using :: to make dynamic libraries it is recommended to use $$(CC.SUFFIX.SHARED) for platform portability. For example, the following will make libabc.dll and libabc.lib on UWIN, libabc.so on Solaris, and libabc.sl on HP-UX:

       libabc$$(CC.SUFFIX.SHARED) :: a.c

2. Support win32 style library name prerequisites
   Unlike UNIX® systems, typical win32 dynamic library names do not begin with "lib". When searching for libraries specified as -lname nmake will search for files both with and without the leading "lib" in the filename such that the following library names can be found: libname.a, name.a, name.lib and libname.lib.
   • The search order for -lname (dynamic libraries take precedence) is: name.lib -> libname.lib -> libname.a -> name.a.
   • The search order for +lname (static libraries take precedence) is: libname.a -> name.a -> name.lib -> libname.lib.
3. The following probe variables have been added
   • CC.SHARED.ALL = -Bwhole-archive
     Option for link editor ld. All members of the libraries following this argument are linked in the generated target. This flag is used to make a dynamic library from a static library and include all the symbols from static library.
   • CC.SHARED.UNDEF = -Bno-whole-archive
     The default option for link editor ld. Only members that resolve undefined symbols in the libraries following this argument are linked in the generated target.
   • CC.SUFFIX.DYNAMIC = .dll
     The suffix for dynamic run-time libraries.
   • CC.SUFFIX.DLL = .exp .def .map
     The suffixes for the supplementary files created when generating dynamic libraries.
4. Support for optional .exe suffix
   On win32 executable binary filenames have a .exe suffix. The executable targets in makefiles do not need to include the .exe suffix. Binary executables will always be generated with the .exe suffix, and nmake can find these executables to match the targets in the makefiles.
5. Support DOS-format makefiles
   Files with DOS style "\r\n" line endings are supported.
6. Support for operation on FAT file systems
7. Support for case-ignorant file systems
   UWIN supports both case-sensitive and case-ignorant file systems. On a case-ignorant file system, mixed case files can be created but file lookup is case-insensitive. nmake supports both case-ignorant and case-sensitive file systems on UWIN.

   This release can not automatically identify the case-ignorant attribute of a file system. The environment variable, case_sensitive_file_system, must be used to inform nmake if a case-ignorant file system is being used. The variable must be exported in the environment and not set on the nmake command line.

   On a case-ignorant file system, case_sensitive_file_system must be unset or set to 0. For example:

       unset case_sensitive_file_system
   	or
       export case_sensitive_file_system=0

   On a case-sensitive file system, case_sensitive_file_system should be set to 1:

       export case_sensitive_file_system=1

   It is the user's responsibility to keep this variable consistent with the setting of the underlying file system. Failing to set it correctly may cause unexpected results. For more information see Limitations.

Change Log

Changes for Release from Pre-release 1

1. 030015 - support Java on UWIN
   The :JAVA: and :JAR: assertions are now supported on UWIN for compiling java code and making jar files. A wrapper comand, npwj, is used to translate UWIN pathnames to native win32 pathnames for the java commands. See the :JAVA: and :JAR: man pages for more information.
2. 040004 - uwin error from :LIBRARY: with -g CCFLAGS
   When CCFLAGS included -g, an archive library named libname-g.a was created, but it tried to generate the shared library from libname.a so it failed. This is fixed and both the archive the shared libraries are generated.
3. 040013 - user doc for java on uwin The :JAVA: and :JAR: man pages included in the nmake_install_root/doc/ directory have been updated for UWIN. A new man page for npwj has been added.

Changes for Pre-release 1 from Beta 1

1. 030026 - support for .exe suffix
   nmake can now bind target executable files with an upper case .EXE suffix, as well as lower case .exe, when the makefile target does not specify a suffix. Previously it only bound to files with a lower case .exe suffix.
2. 030098 - wrong $(VPATH) on case insensitive file systems
   Fixed a problem where nmake ignored the VPATH when working on a case-insensitive file system and the case set in the VPATH for the first node did not match pwd.
3. 030099 - :L operator does not support case insensitive file systems
   The :L edit operator will now properly ignore case when case_sensitive_file_system = 0.
4. 030101 - corrupt state file causes memory fault on UWIN
   nmake can now correctly parse state files containing 0x0d0x0a which previously caused a memory fault.

Limitations

1. The following components are not supported in this release:
   • coshell - for distributed builds
   • nmakelog - for output serialization
   • cpp - the native UWIN cpp, which also supports -I-, is used
   • pax - the native UWIN pax is used
2. Due to the case insensitive file system on win32 some filenames of user makefiles may cause problems. In particular, filenames such as win32.mk, java.mk and jar.mk, in any combination of case, will conflict with the rules files WIN32.mk, JAVA.mk and JAR.mk that are delivered in nmake_install_root/lib/make/. When trying to load a rules file nmake will see the corresponding user makefile first and will not load the necessary rules which will cause build errors. It is recommened to avoid using filenames that differ only by case with files in nmake_install_root/lib/make/.
3. Passing directory paths that contain one or more spaces to the java commands, which use native win32 directory paths, causes errors. On UWIN /home/login usually corresponds to C:\Program Files\UWIN3.1\home, so working with the java tools under the default home directory may cause problems. You must work in a UWIN directory that corresponds to a win32 directory that contains no spaces in the path. Javadeps must also be installed in a similar directory with no spaces in the win32 directory path.
4. Per directory case ignorance is not supported in this release. UWIN allows file systems, and even specific directories, to be mounted as case-sensitive or insensitive regardless of the UWIN global default case setting. At this time nmake does not detect the per-directory case setting. When working on case-ignorant file systems users are encouraged to use all lower-case pathnames wherever possible, such as in makefiles, file systems and the VPATH.