#######################################################
From jonn Fri Dec 14 18:02:28 1990
To: nareng netui williamw
Subject: UI Build News
Date: Fri Dec 14 18:00:35 1990
<EndOfHeader>
(1) OFFICIAL BUILDS
The first official build is coming soon!  A word about official builds:

-- do not use OFFICIAL macro or environment variable
-- do not break official builds
-- official libraries should be in sync with source before official builds

>From our perspective, official builds are much like our regular
development builds, but with the OFFICIAL flag set to TRUE.  You should
never build with OFFICIAL in your makefiles or environment, this is for
builders only.  Your makefiles should not have to worry about OFFICIAL,
just build your targets as normal.

One major difference between ordinary and official builds is that
official builds are supposed to work.  If your project breaks an
official build, LisaCo or possibly AndyH will be displeased.  Your
projects should always build, but for official builds they HAVE to build;
so when you see a notice of an upcoming official build, be sure your
project will not break it.

Another difference is that common libraries are automatically copied
from $(UI)\common\src\<project>\bin to $(UI)\common\lib during an official
build.  Between official builds, you decide when you want to update the
version in $(UI)\common\lib; but in an official build,
$(UI)\common\lib\<yourlib>.lib will automatically be checked out, updated
according to the latest source, and checked back in.  This may break
projects which use your library.  Try not to make changes to the
interface to your library immediately before an official build; and
try to ensure that the projects which import your interface are up-to-date
well in advance of an official build.


(2) $(INCLUDES_ROOTS)
Some of the UI makefiles still do not use $(INCLUDES_ROOTS) in their
DEPEND targets.  The $(INCLUDES_ROOTS) variable expands to

INCLUDES_ROOTS = -P$$(CCPLR)=$(CCPLR) -P$$(COMMON)=$(COMMON)
			-P$$(IMPORT)=$(IMPORT) -P$$(UI)=$(UI)

You should not have to define any -P$$(FOO)=$(FOO) unless you have one
not in INCLUDES_ROOTS;  if you do require one not in $(INCLUDES_ROOTS),
append your extra -P$$(FOO)=$(FOO) before $(INCLUDES_ROOTS), e.g.

INCLUDES_ROOTS = -P$$(FOO)=$(FOO) $(INCLUDES_ROOTS)
or
    - $(INCLUDES) -e -S$(BINARIES_OS2) -L -sobj $(CINC) -P$$(FOO)=$(FOO) $(INCLUDES_ROOTS) *.cxx >> depend.mk

Remember to put your -P$$(FOO)=$(FOO) before $(INCLUDES_ROOTS) if it
should take priority.

Some makefiles under UI which are wong in this respect are:
$(UI)\common\src\blt\blt\makefile
$(UI)\common\src\lmobj\makefile
$(UI)\msgpopup\msgpopup\makefile
$(UI)\netcmd\netcmd\makefile
$(UI)\netcmd\tools\makefile
$(UI)\popup\popup\makefile
$(UI)\shell\comm\makefile
$(UI)\shell\file\makefile
$(UI)\shell\print\makefile
$(UI)\shell\shell\makefile
$(UI)\shell\test\makefile
$(UI)\winpopup\winpopup\makefile

FIX THEM!



#######################################################
From gregj Tue Dec 11 15:29:27 1990
To: chuckc davidhov jonn lisaco
Subject: The for-loop/recursive-make problem
Date: Tue Dec 11 15:27:37 1990

I believe I've found a solution.  It works just fine on
my machine, and I think it'll work in general for the
group.  You may wish to try it yourselves to make sure
it works in general.

The magic command is (for the ALL rule, for example):

for %%i in ($(DIRS)) do (cd %%i && ($(MAKE) $(MAKEFLAGS) all || exit) && cd ..)

Note &&'s instead of &'s, the extra parentheses (which
may or may not be necessary), and the "|| exit".

If the lower level NMAKE fails, the "|| exit" kills the
copy of CMD.EXE that's running the FOR command, with an
error code, so the top-level NMAKE quits nicely.  I'm not
sure of the evaluation order for || and && by default, so
the extra parentheses around the MAKE and EXIT are probably
a good idea.

I knew there had to be SOME way of getting out of a FOR loop...



#######################################################
From chuckc Mon Dec 10 22:44:17 1990
To: netui
Subject: BUILD STUFF. pls read.
Date: Mon Dec 10 22:42:12 1990


    Well guys, just when you it was over...
    Not quite. But good news is, it aint much
    work, if any.

    Below are a few items we need to resolve by
    end of this week. This should be considered high
    priority. If in doubt, pls talk to Jim or your lead.

thx,
chuck


1) breakages
        there were a couple of minor breakages last week when Lisa tried
        to build. I believe all involved have got mail on it. If you have not 
        resolved these breakages by now, pls do so before Weds.
        Weds is when LM21 shoots for a clean build.

2) BUGBUGs, cleanup work, etc.
        pls make it an action item for you to look at BUGBUGs in the
        project you worked on, and try resolve it satisfactorily if you
        can.  if you cannot, pls make a list and send it to me in email.
        Also, pls take a look text at end. A few components still use
        'for' in the makefiles and dont follow the UI tree hierarchy
        properly (esp the UI\COMMON project). If your project don follow,
        pls move it.

3) LM30 specific stuff. 
        there are guidelines for marking components as LM30 specific.
        For the most part, you guys are in good shape, the stuff we do
        are new and clean. Still, I have circulated docs on this on your 
        chairs. Pls read this. If you own an LM30 specific component, like
        USER TOOL, you will have to mark that dir as LM30 only.

4) Code Review
        I will be going thru some makefiles over this week to make sure
        we kind of match the build process. I dont expect major changes, I
        will not be anal about it. So not likely that much will come out of
        this.


------------------------------------------------------------------------------

UI COMMON DIR
-------------

$(UI)
    COMMON
        H               header files, primarily for objects in
                            $(UI)\COMMON\LIB, with which this must be kept
                            in sync.
        HACK            replacement header files for headers in
                            $(COMMON) and $(IMPORT)
        LIB             UI libraries, must be kept in sync with
                            $(UI)\COMMON\H
        SRC
            <proj>
                <proj>  Sources to build project
                BIN     Final and intermediate build targets for BIN and TEST
                            e.g. libraries to be copied to $(UI)\COMMON\LIB.
                            May contain subdirectories for DOS, OS2 if
                            some intermediate targets are not uniquely named,
                            although final build targets must be uniquely
                            named when they can be copied into
                            $(UI)\COMMON\LIB.
                H       Internal header files, plus external header files
                            if the project is not far enough along to put
                            these in $(UI)\COMMON\H.  Should not contain
                            copies or variants of files in $(UI)\COMMON\H.
                TEST    Sources to build test, including test modules
                            temporarily linked into project.  Also
                            includes command scripts and other stuff
                            associated with testing.


$(UI)\COMMON\H, $(UI)\COMMON\LIB
--------------------------------

Common UI header files go into UI\COMMON\H.
Built libs go into your own <proj>\lib, not to COMMON\LIB.
Build process should put it there.
 
Subject: List of offending makefiles
------------------------------------

d:\lm\ui\common\lui\makefile:    for %%i in ($(DIRS)) do cd %%i && $(MAKE) -$(MAKEFLAGS) all && cd ..
d:\lm\ui\common\lui\makefile:    for %%i in ($(DIRS)) do cd %%i && $(MAKE) -$(MAKEFLAGS) clean && cd ..
d:\lm\ui\common\lui\makefile:    for %%i in ($(DIRS)) do cd %%i && $(MAKE) -$(MAKEFLAGS) clobber && cd ..
d:\lm\ui\common\lui\makefile:    for %%i in ($(DIRS)) do cd %%i && $(MAKE) -$(MAKEFLAGS) tree && cd ..
d:\lm\ui\common\lui\makefile:    for %%i in ($(DIRS)) do cd %%i && $(MAKE) -$(MAKEFLAGS) depend && cd ..
d:\lm\ui\common\src\cfgfile\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) all & cd ..
d:\lm\ui\common\src\cfgfile\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) clean & cd ..
d:\lm\ui\common\src\cfgfile\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) clobber & cd ..
d:\lm\ui\common\src\cfgfile\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) tree & cd ..
d:\lm\ui\common\src\cfgfile\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) depend & cd ..
d:\lm\ui\common\src\cui\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) all & cd ..
d:\lm\ui\common\src\cui\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) clean & cd ..
d:\lm\ui\common\src\cui\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) clobber & cd ..
d:\lm\ui\common\src\cui\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) tree & cd ..
d:\lm\ui\common\src\cui\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) depend & cd ..
d:\lm\ui\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) all & cd $(UI)
d:\lm\ui\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) clean & cd $(UI)
d:\lm\ui\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) clobber & cd $(UI)
d:\lm\ui\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) tree & cd $(UI)
d:\lm\ui\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) depend & cd $(UI)
d:\lm\ui\msgpopup\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) all & cd $(UI)\msgpopup
d:\lm\ui\msgpopup\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) clean & cd $(UI)\msgpopup
d:\lm\ui\msgpopup\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) clobber & cd $(UI)\msgpopup
d:\lm\ui\msgpopup\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) tree & cd $(UI)\msgpopup
d:\lm\ui\msgpopup\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) depend & cd $(UI)\msgpopup
d:\lm\ui\setup21\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) all & cd ..
d:\lm\ui\setup21\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) clean & cd ..
d:\lm\ui\setup21\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) clobber & cd ..
d:\lm\ui\setup21\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) tree & cd ..
d:\lm\ui\setup21\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) depend & cd ..
d:\lm\ui\uicore\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) all & cd $(UI)
d:\lm\ui\uicore\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) clean & cd $(UI)
d:\lm\ui\uicore\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) clobber & cd $(UI)
d:\lm\ui\uicore\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) tree & cd $(UI)
d:\lm\ui\uicore\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) depend & cd $(UI)
d:\lm\ui\uicore\uicore\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) all & cd $(UI)\uicore\uicore
d:\lm\ui\uicore\uicore\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) clean & cd $(UI)\uicore\uicore
d:\lm\ui\uicore\uicore\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) clobber & cd $(UI)\uicore\uicore
d:\lm\ui\uicore\uicore\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) tree & cd $(UI)\uicore\uicore
d:\lm\ui\uicore\uicore\makefile:    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) depend & cd $(UI)\uicore\uicore



#######################################################
From jonn Fri Dec  7 16:20:51 1990
To: nareng netui williamw
Subject: UI Build News
Date: Fri Dec 07 16:18:58 1990

(1)  PATH
Be sure to have %LOCALCXX%\BINP on your PATH.  If you don't Glockenspiel
will fail with an unusally cryptic error message.


(2)  $(UI)\COMMON\H, $(UI)\COMMON\LIB
Here's the latest and greatest on what goes where:

$(UI)\COMMON\H, $(UI)\COMMON\LIB:  These are the "released" versions of
your common libraries.  The libraries in LIB should always be in sync with
the header files in H.

$(UI)\COMMON\SRC\<project>\<project>:  The sources for your library.
The library is built into ..\bin[\dos | \os2];  when it is ready, copy it
into $(UI)\COMMON\LIB by hand.

$(UI)\COMMON\SRC\<project>\H:  Internal header files for your library.
If your library has not yet been placed in $(UI)\COMMON\LIB, it is okay
to keep the main header file here as well.  However, if your library has
already been "released," it is not okay to keep a copy of the headers in
$(UI)\COMMON\H here.



#######################################################
From jonn Fri Nov 30 17:56:59 1990
To: nareng netui williamw
Subject: UI Build News
Date: Fri Nov 30 17:55:23 1990
<EndOfHeader>
(1)  NMAKE DEPEND: workaround for bug with includes.exe

IF YOU DON'T READ THIS, YOU MAY BE BREAKING THE BUILD.

If your makefile builds an object from a source file which is referenced
by an absolute path (e.g. c:\foo.c or $(COMMON)\src\server\foo.c) rather
than a relative path (e.g. ..\..\common\src\server.c), you will not be
able to make the dependencies for that object file automatically.

Instead, copy that dependency into your makefile, AND BUGBUG IT.  Replace
the absolute path reference with the appropriate project manifest.  In the
nmake depend section of your makefile, remove that source file from
the arguments to includes.exe.

Here's why:

INCLUDES.EXE has a bug where the -P$$(FOO)=$(FOO) translations are only
done for included files, and not for the source files which were listed
on the command line.  For example,
    [C:\] includes.exe -P$(COMMON)=c:\lm\common c:\lm\common\bar.c
will generate
    bar.obj bar.lst:  c:\lm\common\bar.c
rather than
    bar.obj bar.lst:  $(COMMON)\bar.c
which is what we would have wanted.  This dependency file would break
the build on a machine where $(COMMON) was something other than
c:\lm\common!

We are working on getting the tools group to fix this bug, but in the
meantime the above advice will keep the Long-Haired Build God happy.




(2) INCLUDE, LIB environment variables

Please do not rely on the INCLUDE and LIB environment variables.  As of
now, they are no longer kept current with CINC.  Assume that both of
these are undefined when your project gets built.



(3) A Glockenspiel hint:

Is the Glockenspiel preprocessor GP-faulting on your program?  Does
the C++ compiler returns "too many errors" without troubling to list any
of them specifically?  The problem may be that some of your .cxx and/or
.hxx files are too long.  "Yeah, it'll do that..."



#######################################################
From rustanl Fri Nov 30 11:57:47 1990
To: jonn nareng netui williamw
Subject: Re: UI Build News
Date: Fri Nov 30 11:55:24 1990
<EndOfHeader>

|>From jonn Fri Nov 30 10:28:42 1990
|   [...]
|(2)  CLEAN vs CLOBBER
|   [...]
|clean:
|    -del $(OBJ)
|    -del $(RES)
|    -del *.map
|    -del *.lnk
|    -del *.ixx
|    -del temp1.tmp temp2.tmp

Also, don't forget:

    -del $(CXXSRC:.cxx=.c)

  Rustan



#######################################################
From jonn Fri Nov 30 10:25:47 1990
To: nareng netui williamw
Subject: UI Build News
Date: Fri Nov 30 10:24:13 1990
<EndOfHeader>
(1) Upper-level makefiles
In a previous message I discussed how to build a makefile like this:

all:
    for %%i in ($(DIRS)) do cd %%i & $(MAKE) -$(MAKEFLAGS) all & cd ..

Unfortunately, this doesn't work.  If one of the lower-level makes
fails, the loop will continue, even though it should fail.  Sorry,
you'll have to do this the long way.  (Or do you have suggestions on how
we can do this right?)


(2)  CLEAN vs CLOBBER
Just to clarify:  CLEAN deletes all intermediate files  (most, but not
all, .OBJ files fall into this category), while CLOBBER deletes
intermediate files and final build targets.  The CLOBBER build target
always implies clean.  Here are some example CLEAN and CLOBBER targets:

all: $(APP)

clean:
    -del $(OBJ)
    -del $(RES)
    -del *.map
    -del *.lnk
    -del *.ixx
    -del temp1.tmp temp2.tmp

clobber: clean
    -del $(APP)

As a general rule, CLEAN should leave nothing behind but final build
targets and SLMed files, while CLOBBER should leave only SLMed files.

IMPORTANT:  Neither CLEAN nor CLOBBER should delete any SLMed files!

BTW, the "<$(YES)" is only required for "del ..\bin\*.*".



#######################################################
From jonn Wed Nov 28 18:11:27 1990
To: nareng netui williamw
Subject: UI Build News
Date: Wed Nov 28 18:10:05 1990
<EndOfHeader>

(1)  -DNOT_MS_CCPLR
The file $(UI)\common\hack\netcons.h has been removed, and we are now
using the standard netcons.h.  If you are including netcons.h in a C++
program, you must define the macro -DNOT_MS_CCPLR to avoid a pragma
which will crash Glockenspiel.

This macro is now included in the standard CXFLAGS in uiglobal.mk, so as
long as you use the standard CXFLAGS (or just expand it), you should do
fine.


(2)  $(MAKEFILE)
The template project $(UI)\logon used a makefile rule like this:
$(DEF): $(MAKEFILE)
    echo foo bar >$(DEF)
There are two problems with this:

-- $(MAKEFILE) is not a predefined macro, and so this rule will not
trigger on an updated macro.  Use "makefile" rather than "$(MAKEFILE)".

-- The line in the $(DEF) file will be terminated in a space, which may
confuse $(BIND).  Remove the extra space.

| From gregj Wed Nov 28 18:27:39 1990
| To: jonn nareng netui williamw
| Subject: UI Build News
| Date: Wed Nov 28 18:24:36 1990
| <EndOfHeader>
| 
| Third problem:  if you're building a big file, this is slower than shit.
| Use nmake's inline file capabilities instead, viz:
| 
| $(DEF): makefile
| 	@echo Building $@
| 	@rem <<$(DEF)
| NAME FOO WINDOWCOMPAT
| DESCRIPTION 'The niftiest utility in LANMAN'
|  .
|  .
|  .
| EXPORTS ClientWndProc		[last line in file]
| <<KEEP
| 
| Note that the lack of a space after the << (both places) is important;
| nmake won't recognize it otherwise.  I can build a thirty-line linker
| response file in about a second this way, compared with a couple of
| minutes having to exec cmd.exe for every line.
| 
| Helpful hint:  Read the NMAKE documentation that comes with C6, or
| the quickhelp for it.  There are a lot of very useful and very obscure
| features (like this one) in there.



#######################################################
From chuckc Wed Nov 28 11:04:38 1990
To: netui
Subject: HACK no more
Date: Wed Nov 28 11:03:07 1990
<EndOfHeader>

Apologies for sending mail a bit late, got tired by the time
I hacked the hack last night.

Pls disregard mail earlier today on using stuff in the
hack directory. as part of the LM30 integration, I'm
slowly but surely nuking it. 

As a result of last night's cleanup, you may suffer breakages
as oulined below. But its worth fixing it now rather than having
to maintain HACKed up files for always. So bear with me.

1) NETCONS.H used to be needed since it had a pragma which
   kills Glock. Now that pragma if ifdef-ed out if you have
   NOT_MS_CCPLR defined. See rules.mk in ui\shell.

2) NETLIB.H used to break Glock as well because of NetISort().
   DavidHov has provided an alternative syntax Glock takes, and
   I've fixed it as such. So, use the official one, hack no more.
   If you include NETLIB without including NETCONS.H then you will 
   have problems. Also, do not do #define OS2_INCLUDED and then
   include NETCONS.H. This will cause it not to pick some stuff
   up and most things will break. I've fixed it in a few places,
   but I'm sure I have not caught all.

3) NET32DEF.H was also in HACK directory. I've also nuked this
   because we dont need it. 
   

Steps you should take?
	1) ssync in UI\COMMON\HACK (hacked files get nuked)
	2) ssync in  COMMON\H (pickup clean files)
	3) nmake depend in your own project
	4) make sure rules.mk has NOT_MS_CCPLR defined if Glock
	5) build the fucker, flame me if it breaks.



#######################################################
From jonn Wed Nov 28 09:41:02 1990
To: nareng netui williamw
Subject: UI Build News
Date: Wed Nov 28 09:39:31 1990
<EndOfHeader>
(1)
Just in case you missed it:  it's OK to SLM again.

(2)
Please do not rely on the LIB or INCLUDE environment variables.  Every
library should be referenced starting from an environment variable (e.g.
$(COMMON), $(IMPORT), $(UI), etc. ).  Every include file should be on the
CINC include path (it is acceptable to reference $(COMMON)\src\project\foo.h
as "project/foo.h").  The latest $(COMMON)\src\setenv.cmd does not set LIB
or INCLUDE at all.

(3)
A complete list of the UI Build News is available as $(UI)\common\src\hints.



#######################################################
From jonn Tue Nov 20 13:27:53 1990
To: nareng netui williamw
Subject: UI Build News
Date: Tue Nov 20 13:29:39 1990

(1)
The DEPEND makefile target should _not_ check depend.mk out or in.

(2)
Projects which should compile under C510 can now use the C510 manifest.
Just define
C510 = TRUE
_before_ you include uiglobal.mk.  This should replace the previous
method of defining
CCPLR = $(IMPORT)\C510
LINK4 = $(CCPLR)\bin\link4.exe

(3)
If you want a local copy of C510 and/or C600, without having to enlist in
the immense $(IMPORT) share, define one or both of the following macros:
CCPLR_C510 = c:\myc510
CCPLR_C600 = c:\myc600
(replacing the path as appropriate).  Be certain that your local copy
is a complete copy of what is in $(IMPORT), including the bin, h and lib
directories.



#######################################################
From jonn Mon Nov 19 17:59:17 1990
To: nareng netui williamw
Subject: UI Build News
Date: Mon Nov 19 17:57:59 1990

Just one item today:

(1)
PLEASE do not place
    clean:
        -del *.*
in your makefiles!  This is very dangerous!  You'll have to be a little
pickier...



#######################################################
From jonn Fri Nov 16 13:44:45 1990
To: nareng netui williamw
Subject: UI Build News
Date: Fri Nov 16 13:43:31 1990

More pointers as we head into the home stretch:

(1)
Earlier I discussed one method of keeping build targets and
intermediate files seperate for variants of a project (e.g. DOS, OS2
etc.)  Here's another:

When you build different versions of your object, name the targets AND
OBJECT FILES differently.  For example, one variant could use the ".obj"
extension, another ".obs" and another ".oba".

See $(COMMON)\src\canon\makefile and rules.mk for examples.


(2)
You may be having problems with the length of the command line under
C510.  If your command line is too long, the compiler will fail without
an error message.  The following macros will remove some of the -I
statements added by uiglobal.mk and should relieve this problem:
#define NOUIINCLUDES  ;  do not add any UI-specific include directories
#define NOUICOMMON    ;  do not add the $(UI)\common\h directory
#define NOUIHACK      ;  do not add the $(UI)\common\hack directory
                        ;  this macro may also be useful if you want the
                        ;  unhacked version of the hacked include files


(3)
The $(YES) macro is now available to replace $(COMMON)\bin\yes.txt, e.g.
    -del foo.bar <$(COMMON)\bin\yes.txt
becomes
    -del foo.bar <$(YES)


(4)
Some projects contain dependencies for the DEPEND target, e.g.
    depend: $(MAKEFILE) rules.mk ..\rules.mk  <etc>
The DEPEND target should contain no dependencies, but should always be
rebuilt when requested.



#######################################################
From jonn Wed Nov 14 18:21:55 1990
To: nareng netui williamw
Subject: UI Build News
Date: Wed Nov 14 18:20:47 1990

(1) REAL MODE LIBRARIES
Manifests are available for the real-mode C libraries -- use
CLIB_XLIBCR [replacing X by S, M or L]

(2) BUILDING LIBRARIES
Really clever makefile tricks are available to build libraries, e.g.
    !$(LIBUTIL) $(TARGET_LIB)-+$?
See $(COMMON)\src\netlib\makefile for an example.



#######################################################
From jonn Tue Nov 13 16:42:18 1990
To: nareng netui williamw
Subject: Build News
Date: Tue Nov 13 16:42:53 1990

No immediate changes to your makefiles today, but the following changes
will be made if no one objects:


(1)
Should the $(UI)\common\hack include files be on your path by default?
At present, they are.  Unless someone objects, this will be changed so
that you must define INCLUDES_UIHACK to get these include files
(replacing manifest NOUIHACK which prevented their inclusion).


(2)
JohnL and I propose the following changes to ENVDEF.H and the base
include files:
-- ENVDEF.H will include standard base types for UI, especially those
   which appear in more than one of OS2DEF.H, NETCONS.H, and WINDOWS.H.
-- ENVDEF.H will be moved into the $(UI)\common\hack directory.
-- ENVDEF.H will appear first on the list of include files, rather than
after other system include files.  OS2.DEF, NETCONS.H and WINDOWS.H will
have hacked versions in the HACK directory which have the types in
ENVDEF.H "#ifdef _ENVDEF_H_"ed out.
-- The manifest ENVDEF_OS2BOOL will select OS2-style BOOL (USHORT)
rather than Windows-style BOOL (int).


(3)
You should keep major variants of your object files and build targets in
separate subdirectories of ..\bin, for example ..\bin\dos and
..\bin\os2.  You will want to redefine the $(UI)\common\src\uiglobal.mk
inference rules to build to your new directory, for example
uiglobal.mk
-----------
{}.cxx{$(BINARIES)}.obj:
        $(CCXX) $(CXFLAGS) $(CINC) $<
        $(MV) $(<:.cxx=.c) $(BINARIES)\$(<:.cxx=.c)
        $(CC) $(CFLAGS) -Fo$*.obj $(CINC) -c $(BINARIES)\$(<:.cxx=.c)

$(UI)\<project>\rules.mk
------------------------
BINARIES_DOS=$(BINARIES)\dos
{}.cxx{$(BINARIES_DOS)}.obj:
        $(CCXX) $(CXFLAGS) $(CINC) $<
        $(MV) $(<:.cxx=.c) $(BINARIES_DOS)\$(<:.cxx=.c)
        $(CC) $(CFLAGS) -Fo$*.obj $(CINC) -c $(BINARIES_DOS)\$(<:.cxx=.c)



#######################################################
From jonn Fri Nov  9 16:36:21 1990
To: nareng netui williamw
Subject: Build News
Date: Fri Nov 09 16:35:37 1990

Important build news going into the weekend...

(1)
$(COMMON)\src\global.mk and $(COMMON)\src\setenv.cmd have been updated.
Please ssync if you are enlisted.

(2)
$(UI)\common\src\global.mk has been updated and renamed to uiglobal.mk.
Please ssync and update all references.

(3)
Please rename your %LOCALCXX%\bin directory, back to %LOCALCXX%\binp.

(4)
$(UI)\common\src\setenvui.cmd has been removed.  Please refer to
$(COMMON)\src\setenv.cmd.  Especially don't forget to
-- put %LOCALCXX%\binp on your path
-- define the $(UI) environment variable

(5)
You can remove
LIB=$(LIB)
and
INCLUDE=$(INCLUDE)
from all of your local makefiles and rulesfiles.


As always, $(UI)\logon is a template for the latest and greatest.




Jon Newman



#######################################################
From jonn Thu Nov  8 17:30:40 1990
To: nareng netui williamw
Subject: UI Build News
Date: Thu Nov 08 17:29:54 1990

(1)
UI projects may remove $(UI)\common\hack from their include path by
defining the NOUIHACK manifest _before_ they include rules.mk., e.g.
in file $(UI)/<myproject>/rules.mk,

# @@ COPY_RIGHT_HERE
# @@ ROADMAP :: The Rules.mk for the product-wide header files

NOUIHACK=TRUE

!include $(UI)\COMMON\src\global.mk

...



(2)
Good news for porting old programs:  You are welcome to continue using
C510 when porting projects which were originally written for C510.  Projects
under $(UI) will otherwise use C600a by default (but default is C510 for
projects not under $(UI)).  To do this, add

# BUGBUG - uses C510, not C6 as rest of UI project
CCPLR    = $(IMPORT)\c510
LINK4    = $(CCPLR)\bin\link4

to your rules.mk, _after_ "!include <whatever>\{rules | global}.mk".



#######################################################
From jonn Wed Nov  7 19:57:09 1990
To: netui
Subject: Build News
Date: Wed Nov 07 19:56:28 1990

(1)
$(BINARIES) is back in style.  If you build your binary files to
somewhere other than ..\bin, be sure to redefine this macro.  You can
therefore use

CXXSRC = .\logon.cxx .\strings.cxx .\general.cxx
CXXTMP = $(CXXSRC:.cxx=.obj)
CXXOBJ = $(CXXTMP:.\=..\bin\)


(2)
You should no longer need the WINDEV environment variable.  The SDK
libraries are now available in $(UI)\IMPORT\WIN30\LIB, but since they
will move, refer to them only through the new BUILD_WINLIB macro.


Please do SSYNC to the latest $(UI) stuff.  As always, see
$(UI)\LOGON for the latest example project.

If you have suggestions or gripes on the new build process, please write
them up as mail and send it to me.

Jon Newman

