Conference smurf::buildhelp

Date Of Receipt: 	19-MAY-1993 12:15:23.70
From: 	FLUME::"[email protected]" "Grant Van Dyck"
To: 	"Michael D. Fairbrother" <[email protected]>
CC: 	[email protected], [email protected], [email protected]
Subj: 	Re: libtli Makefile problem...

| Currently the shared version of libtli gets built before the
| non shared version, this is caused by the lists in which the
| libraries appear.
| 
| 
| in ./usr/shlib/Makefile is in EXPSHLIB_SUBDIRS (built in 4'th pass of build)
| in ./usr/lib/ccs/Makefile is in EXPLIB_SUBDIRS (built in the 5th pass of buil
d)

But in the nightly build, because of the way the libraries are built
the reverse is true.  From agosminor:

vandyck@stack [23] pwd
/usr/build/osf1/agosminor.bld/export/alpha/usr
vandyck@stack [24] ll ccs/lib/libtli.a
-rw-r--r--   1 devbld   system    266540 May 18 21:20 ccs/lib/libtli.a
vandyck@stack [25] ll shlib/libtli.so
-rw-r--r--   1 devbld   system    113269 May 18 22:22 shlib/libtli.so
vandyck@stack [26] 



			-Grant

Date Of Receipt: 	19-MAY-1993 13:45:47.99
From: 	FLUME::"[email protected]" "Grant Van Dyck"
To: 	"Michael D. Fairbrother" <[email protected]>
CC: 	[email protected], [email protected], [email protected],
	[email protected]
Subj: 	Re: libtli Makefile problem...

| 
| Grant if by chance someone adds a new EXPLIB_SUBDIRS directory (let say 
| etc) in the top level Makefile file, will the nightly build that does
| not work off of Makefiles know about this and make sure that its done
| in the proper order?  I think there's a good reason for having a multiple
| phase build, and that any tools that get created to reduce the overall
| build time might want to take advantage of this, or at least not break it.

Everything works off Makefiles, It's just that ccs/lib and shlib get built
in parallel. If something unexpected appears, it gets caught in the final_pass
and built as the developer intended. What I plan to do is to take the same
cmd built ordering technology and apply it to libs as well.  So far I don't 
know of anything that's broken by the way nightly is building things. 
If you find something, let me know and I'll fix the script.

| 
| Maybe someone could do some advance development work to see what it will
| take to get the ODE 1.2 make into the development area, it has built in
| features that allow for concurrent compiles.  Along with a slew of other
| benefits, (OSF, switched a while back when I was still part of the 
| porting lab...)
| 

I had a discussion with Darrell about this. I was for it, so was he I think.
He felt it should be a side project/SSB like security with 1 or 2 Engineers
working on the Makefile changes with regular full build/installs against it.

There is some other thought on the subject, like dependency mapping etc.
We must be able to make the build comprised of many independent chunks,
though, as we must try and move toward distributed - multi-threaded builds
and not single threaded single processor builds (one of my side projects).


	-Grant

Date Of Receipt: 	19-MAY-1993 14:35:21.40
From: 	KRISIS::"[email protected]" "Carolyn Hurley"
To: 	Grant Van Dyck <[email protected]>, [email protected]
CC: 	[email protected], [email protected], [email protected]
Subj: 	Re: libtli Makefile problem...

My two cents worth... I don't think the "ODE 1.2" make that Mike is
referring to is not posix compliant.  OSF ships a different make in 
their product (a posix compliant make) and builds their OSF V1.1 
and OSF V1.2 products with what Mike is calling the "ODE 1.2 make". 
Therefore you can not build OSF sources with the make that is
shipped as part of the product. (confusing??) Refer to old mail from 
Dave Snow below.
  

/Carolyn

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

Return-Path: rust::[email protected]
Received: by wasted.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91);
	id AA20678; Mon, 3 Aug 1992 12:18:42 -0400
Date: Mon, 3 Aug 1992 12:18:40 -0400
From: rust::[email protected]
To: WASTED::zap
Subject: Re: Make confusion - need clarification

SILVER make :                   From OSF/1, same as OSF V1.0 make and OSF/ODE 
                                V1.0 make, except for any work you may have 		
				done.
DEC/ODE II V1.3 make :          Early non-|| version of make used by OSF to
                                make OSF1.1 in the summer of 1991.
                                (Came from BSD Reno make, but has
                                some of the CMU/ODE changes added)
DEC/ODE II V1.4 make :          Current || version of make used by OSF to
                                make OSF1.1. This is the same as OSF/ODE V1.1
                                make, except for bug fixes. Came from OSF/ODE
				V2.1.0
                                (Mar 1992)
ODE II odeman page make:        Manpage from OSF for the make shipped on our
                                ode kit. As with most of OSF's douumentation it
                                may be out of date when we get it from them. We
                                plan to improve and update it for DEC/ODE V2.0.
                                We would welcome any input for this.
OSF/ODE V1.0 make               Before my (our) time this was in the summer
                                of 1990
OSF/ODE V1.1 make :             There is no such thing. I Think you mean
                                OSF/ODE V2.1.0 or V2.1.1
                                The same as DEC/ODE II V1.4
OSF V1.1 make:                  This is a new cut at the BSD reno make without
                                any || features, or any CMU/ODE features, and
                                has been modified to be POSIX compliant. This 		
				make can not be used to make OSF V1.1 using 
				the makefile that OSF and we ship!
OSF V1.0 make:                  This is the CMU/ODE make that we and OSF used to
                                make OSF1 (V1.0)

>If there are slight variations (ie improvements or bugfixes) between
>makes could you please specify that there is?  For example, we are very
>interested to know how the DEC/ODE II v1.4 make varies from the OSF/ODE V1.1 
make??


ODE V1.4 Make is the OSF/ODE V2.1.0 (Feb 92) make with the following change:
    We look for the default rules (which ODE doesn't use) in /usr/sde/lib
    rather than /usr/lib.

    In ODE V1.3 we also fixed make to correctly follow links, and thought
    that OSF had also fixed this, but they had not and we missed those changes.

We do have OSF/ODE V2.1.1 and its make with not many changes and that is what
we plan to ship with ODE V2.0.  We Have added the fixes to follow links, and 
I believe that this is the version  that we are testing to see if we have
fixed the signal 11 problem in. If it is needed sooner we could work somthing 
out.


We have doen very little with make. The reason that we moved the location of the
rules file was that on ULTRIX systems there was no rules file and if a user
had our make in his path he couldn't use it to make other things.  Today we 
should
probably make that look first in /usr/lib then in /usr/sde/lib. This only 
people not using ODE but with the ODE tools first in their path.


For sum reason OSF keeps shipping make that doesn't follow links, and this has
bad effects on projects that use links a lot. We have tried to see that our
version does what is "normal" for make and follwo the links. OSF problem in
this area comes from the fact that a link, can be either pointer to a target
of the make rule or the object of a make rule, if you have rules that 
create links.


I hope that this helps,

/dave

Date Of Receipt: 	19-MAY-1993 15:52:50.62
From: 	FLUME::"[email protected]" "Grant Van Dyck"
To: 	[email protected]
CC: 	[email protected], [email protected], [email protected],
	[email protected]
Subj: 	Re: libtli Makefile problem...

I talked to Dave about this a month or so ago, and I don't think
that the idea was to use the 1.2 make "straight out of the can",
but rather to merge the two so that you'd either have a 1.0 make
that knew how to be multi-threaded, or a 1.2 make that had all
of our functionality and changes.

	-Grant
| 
| 
| My two cents worth... I don't think the "ODE 1.2" make that Mike is
| referring to is not posix compliant.  OSF ships a different make in 
| their product (a posix compliant make) and builds their OSF V1.1 
| and OSF V1.2 products with what Mike is calling the "ODE 1.2 make". 
| Therefore you can not build OSF sources with the make that is
| shipped as part of the product. (confusing??) Refer to old mail from 
| Dave Snow below.
|   

Date Of Receipt: 	19-MAY-1993 13:38:44.92
From: 	LOCORE::decwet::peterson
To: 	LOCORE::"[email protected]"
CC: 	LOCORE::"[email protected]", LOCORE::"[email protected]"
Subj: 	RE: syntax in makefiles for including other files

The ODE documentation is for the make distributed with ODE, which is what Mike 
refers to in the enclosed mail as ODE 1.2 make (and we refer to as ODE II).  The 
DEC/OSF1 product uses its own make (ODE I make), and it has different syntax as 
you discovered.
--Kim
=============================================================
Date:	19-MAY-1993 09:27:19.01
From:	MINSRV::"[email protected]"
Subj:	Re: libtli Makefile problem...  
To:	Grant Van Dyck <[email protected]>
CC:	"Michael D. Fairbrother" <[email protected]>, [email protected],
	[email protected], [email protected], [email protected]
49 records, external message id MAIL$CBB0421700050096.MAI
Attributes: None 
...
Maybe someone could do some advance development work to see what it will
take to get the ODE 1.2 make into the development area, it has built in
features that allow for concurrent compiles.  Along with a slew of other
benefits, (OSF, switched a while back when I was still part of the 
porting lab...)

mdf.
=============================================================================
From:	LOCORE::"[email protected]"   19-MAY-1993 10:25:43.59
To:	[email protected]
CC:	
Subj:	syntax in makefiles for including other files


What is the proper syntax to include other files within a makefile?

FYI:

The ODE-II Developer's User Guide and the ODE training slides says:

		. include "file"

But in the makefiles found in the backing trees the syntax is:

		  include "file"  ( no dot )

I guess the docs are wrong. Or am I missing something? 


Rich
----------------------------------------------------------------
Rich Larsen, M/S: UNX			TCP/IP: [email protected]
USSG/User Env. & Std. Group		DECnet: UNXA::LARSEN
Digital Equipment Corporation		FAX:	908-577-6003
200 Route 9 North			Voice:	908-577-6083	
Manalapan, New Jersey 07726		DTN:	462 

Date Of Receipt: 	20-MAY-1993 11:58:54.02
From: 	MINSRV::"[email protected]"
To: 	"Michael D. Fairbrother" <[email protected]>
CC: 	[email protected], [email protected],
	[email protected], [email protected]
Subj: 	Re: libtli Makefile problem...

Michael-
In general it is not a good idea to build shared libaries from static ones
for the following reasons:
    1: In the original OSF source shared libraries and sticic libraries
       were build with different pre-defines. Part of this was do to OSFs
       shared library implementation. 

    2: libc.so is built with different pre-defines tham libc.a. I can't
       remember what the exact differences are but they do exist.


The advantage of building from the .a is that you remove the problem
of adding a file to one Makefile and not the other. (We often had this
problem with the libc.so Makefile). 

In general, I would be leary of change or current build mothods.
I think it would be a lot of work to prove that the modified
procedure produced the same results as the previous.

That my two cents.

Brett


> Currently the shared version of libtli gets built before the
> non shared version, this is caused by the lists in which the
> libraries appear.
> 
> 
> in ./usr/shlib/Makefile is in EXPSHLIB_SUBDIRS (built in 4'th pass of build)
> in ./usr/lib/ccs/Makefile is in EXPLIB_SUBDIRS (built in the 5th pass of buil
d)
> 
> Is it a good practice to build shared libraries from static libraries?  If
> so than maybe passes.mk should change to build all the static libraries 
> before the shared versions...
> 
> mdf. 
> 
> =====================================================================
> Michael D. Fairbrother, M/S: ZKO3-3/U14     TCP/IP: [email protected]
> Digital Equipment Corporation     DECnet: RUDDY::MDF
> 110 Spit Brook Road               Voice:  603-881-2399 (DTN-381-2399)
> Nashua, New Hampshire 03062-2698  FAX:    603-881-2257 (DTN-381-2257)
---------
Brett Sampson                          tcp: [email protected]
Digital Equipment Corporation
USG/Unix Engineering                   DECnet: aosg::sampson
MS ZK3-3/Y25
Nashua, NH                             tx: 603/881-2967  (DTN 381-2967)

Date Of Receipt: 	19-MAY-1993 12:27:15.08
From: 	MINSRV::"[email protected]"
To: 	Grant Van Dyck <[email protected]>
CC: 	"Michael D. Fairbrother" <[email protected]>, [email protected],
	[email protected], [email protected], [email protected]
Subj: 	Re: libtli Makefile problem...

Grant if by chance someone adds a new EXPLIB_SUBDIRS directory (let say 
etc) in the top level Makefile file, will the nightly build that does
not work off of Makefiles know about this and make sure that its done
in the proper order?  I think there's a good reason for having a multiple
phase build, and that any tools that get created to reduce the overall
build time might want to take advantage of this, or at least not break it.

Maybe someone could do some advance development work to see what it will
take to get the ODE 1.2 make into the development area, it has built in
features that allow for concurrent compiles.  Along with a slew of other
benefits, (OSF, switched a while back when I was still part of the 
porting lab...)

mdf.
>
>
>| Currently the shared version of libtli gets built before the
>| non shared version, this is caused by the lists in which the
>| libraries appear.
>| 
>| 
>| in ./usr/shlib/Makefile is in EXPSHLIB_SUBDIRS (built in 4'th pass of build)
>| in ./usr/lib/ccs/Makefile is in EXPLIB_SUBDIRS (built in the 5th pass of bui
>l
>d)
>
>But in the nightly build, because of the way the libraries are built
>the reverse is true.  From agosminor:
>
>vandyck@stack [23] pwd
>/usr/build/osf1/agosminor.bld/export/alpha/usr
>vandyck@stack [24] ll ccs/lib/libtli.a
>-rw-r--r--   1 devbld   system    266540 May 18 21:20 ccs/lib/libtli.a
>vandyck@stack [25] ll shlib/libtli.so
>-rw-r--r--   1 devbld   system    113269 May 18 22:22 shlib/libtli.so
>vandyck@stack [26] 
>
>
>
>			-Grant


=====================================================================
Michael D. Fairbrother, M/S: ZKO3-3/U14     TCP/IP: [email protected]
Digital Equipment Corporation               DECnet: RUDDY::MDF
110 Spit Brook Road                         Voice:  603-881-2399 (DTN-381-2399)
Nashua, New Hampshire 03062-2698            FAX:    603-881-2257 (DTN-381-2257)