Nokia Networks Home

Nokia nmake Product Builder

Quick Links

Related Products

Nokia nmake - UWIN Platform Notes

nmake for UWIN allows the use of nmake on the Windows® 2000 operating systems running UWIN 3.1.


  1. UWIN release 3.1. Note, nmake uses the UWIN cpp and UWIN cc wrapper; some UWIN packages may not have these components.
  2. 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.
  3. Product requires maximum 25MB disk space including user manuals. Actual disk requirements may be less depending on platform.
  4. nmake will run on any CPU capable of supporting the host OS and platform environment; there are no special CPU requirements.


  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
    • native win32 Java SDK 1.4.1 and 1.4.2
  3. Makefiles: A primary goal 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 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 "*<>|.


  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, on Solaris, and 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
        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.

General Notes

  1. The following components are not supported:
    • 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. Java builds are supported.
  3. Files with DOS style "\r\n" line endings are supported.
  4. Due to the case insensitive file system on win32 some filenames of user makefiles may cause problems. In particular, filenames such as, and, in any combination of case, will conflict with the rules files, and 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/.
  5. 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.
  6. Per directory case ignorance is not supported. 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.
Last Update: Friday,12-Aug-2016 12:12:54 EDT