Conference smurf::buildhelp

Date Of Receipt: 	 4-APR-1995 15:41:16.65
From: 	SMURF::FLUME::"vandyck%[email protected]"
To: 	anderson@dec:.zso.decwet (Tina Anderson)
CC: 	flume::odehelp
Subj: 	Re: kernel build question

Actually I asked him to file this as a PTT as its really a change to RCS/bco 
he's looking for. When you check out a file you get the public branch version 
(as you should) but a private branch has been created for the checkout.

The RCS id string in the file is the Public one, not the private branch one as 
happens when you do check it in.  

For Example:

PTOS version of foo.c is 1.2.3.?

jon_doe_branch is 1.2.4.1

but the string in the file is 1.2.3.?


If he checks in the file unchanged, then checks it out again, he'll get
1.2.4.2. When he builds a kernel, he can find this ID string to compare 
various kernels under test (what vmunix | grep foo.c).

What he'd like is to get 1.2.4.1 as the ID string the first time and not have 
to do the extra bci/bco.  This really has nothing to do with the kernel per se 
and is clearly a tool change he's requesting to simplify his work using 
existing interfaces.

Is this a difficult thing to change?


	-Grant


| Hi,
| This ptt came in last month.  I think this is more
| a build issue and not a ode issue.  The code could have
| keywords that could be expanded that this person could
| look for.  I am not that familiar with the kernel builds.
| What do you think.  Who could I forward this to?
| 
| Thanks,
| Tina
| 
|           Action Problem                                               Last
| Number    Status Status Prior Owner        PRODUCT         Flags Age  Updated
| ======    ====== ====== ===== =====        =======         ===== ===  =======
| ODE-00376 RC     UN     3     ODE_ZSO      ODE                  28  7-MAR-199
5
| DEC -BCO should modify ID string of checked out source.
| 
| 
| (internal number: 00376)
| Submitted by: MIKE SCHLOSS USG          of USG-ZK             in USA
|         (381-2693)
|         Mail address: RUST::"[email protected]"
| 
| 
| PROBLEM ABSTRACT (80 characters or less):
| BCO should modify ID string of checked out source.
| 
| When I check out a source, modify it, and build it,
| there is no way for me to distinguish the object.
| Other source control systems that I have used make
| it a point to differentiate the ID string when the
| branch is created.  The one I have in mind went as
| far to mark the locked/unlocked status in the build
| string.  This enabled us to reject temporary objects
| (built from non-checked-in source) and also let us
| see if our changes propogated as expected.  For
| instance,  If I check-out FOO.H which was at 3.4,
| I may get 3.4.6.0.  If I scan the kernel for ID
| strings and I find "FOO.H - 3.4" as well as
| "FOO.H - 3.4.6.0" then I know that my file did
| not propagate properly through the build.
| 
| 
| Instructions to reproduce the problem:
| ======================================
| 
| Check out a source file, modify it, and do a build.
| Now prove that the resultant binary actually used
| your source file and not one from somewhere else in
| the tree.  This works best (results in the most
| confusion) if the source file is a header file that
| resides in multiple places in the build tree.
| 
| Results from currentsb -all:
| ============================
| sb Michael_Schloss_sb /work . /work/sb/rc_files/local /tmp_mnt/cia/share/cia/
bi
| ld/ptos.dsk6/ptos.nightly0

Date Of Receipt: 	 4-APR-1995 16:27:20.48
From: 	SMURF::FLUME::jmcg "Jim McGinness"
To: 	odehelp@DEC:.zko.flume
CC: 	schloss@DEC:.zko.flume
Subj: 	Re:  kernel build question

Mike's making a fairly reasonable enhancement suggestion, but implementing it
within what we have would be a fairly large amount of work.  I assume
he knows how to use the SCCS "what" command or the RCS "ident" command.

1) We currently don't have #pragma ident strings in header files.  These
would be required to do the tracking Mike desires.  It will cost some
space to keep the additional information in the object files.  I'm not
even sure if #pragma ident will work this way.

2) I read Grant's clarification.  I hadn't noticed that the new file checked
out on a private branch doesn't show the Revision of the private branch, but
testing shows it to be true.  This would need to be fixed, but the workaround
is to do an immediate bci -l after bco.

3) In addition to having the correct Revision, we would also need to add
the $Locker$ keyword to the ident string.  This would cover the difference
between a file that is still checked out for edit, thus able to change
without a new Revision number being assigned, and a file that has been
committed to the RCS tree.  This comes close to what I think Mike was
asking for.

4) Our ident strings only show the base filename of a file, not the entire
path.  For the fine-scale tracking that Mike is asking for, it might be
necessary to include full pathnames.  These pathnames are already embedded in
the object file's debug symbol table information, so it wouldn't be too much
of a stretch to have them in the ident string (but it would make the eyes
sorer to look at them and take up more disk space).

 -- jmcg

Date Of Receipt: 	 4-APR-1995 16:45:35.77
From: 	SMURF::ALPHA::schloss "Mike Schloss usg  04-Apr-1995 1644"
To: 	Jim McGinness <jmcg@DEC:.zko.alpha>
CC: 	odehelp@DEC:.zko.alpha
Subj: 	Re: kernel build question

> Mike's making a fairly reasonable enhancement suggestion, but implementing it
> within what we have would be a fairly large amount of work.  I assume
> he knows how to use the SCCS "what" command or the RCS "ident" command.

Yes

> 1) We currently don't have #pragma ident strings in header files.  These
> would be required to do the tracking Mike desires.  It will cost some
> space to keep the additional information in the object files.  I'm not
> even sure if #pragma ident will work this way.

A quick test shows that #pragma ident works just fine with header files.
Actually, the header aspect of it is irrelivant.  Multiple #pragma ident
constructs appear to just add the specified strings.  Redundancies are
NOT eliminated.

> 2) I read Grant's clarification.  I hadn't noticed that the new file checked
> out on a private branch doesn't show the Revision of the private branch, but
> testing shows it to be true.  This would need to be fixed, but the workaround
> is to do an immediate bci -l after bco.
> 
> 3) In addition to having the correct Revision, we would also need to add
> the $Locker$ keyword to the ident string.  This would cover the difference
> between a file that is still checked out for edit, thus able to change
> without a new Revision number being assigned, and a file that has been
> committed to the RCS tree.  This comes close to what I think Mike was
> asking for.

Yes.

> 4) Our ident strings only show the base filename of a file, not the entire
> path.  For the fine-scale tracking that Mike is asking for, it might be
> necessary to include full pathnames.  These pathnames are already embedded in
> the object file's debug symbol table information, so it wouldn't be too much
> of a stretch to have them in the ident string (but it would make the eyes
> sorer to look at them and take up more disk space).

Full pathnames might be nice but don't provide much more information unless
the compiler/preprocessor fills it in.  The current build procedure copies
header files and uses them from the new location so this could not be used
to resolve differences between export/alpha/usr/include/syy/foo.h,
obj/alpha/usr/include/sys/foo.h, and obj/alpha/kernel/include/sys/foo.h.

Mike

Date Of Receipt: 	 4-APR-1995 18:33:36.74
From: 	SMURF::FLUME::jmcg "Jim McGinness"
To: 	schloss@DEC:.zko.flume
CC: 	odehelp@DEC:.zko.flume
Subj: 	Re: kernel build question

Actually, there'd be a difference between the pathname the compiler records
for a file and the pathname we'd have RCS insert.  The output of a blog -r
command shows an "RCS file:" pathname, which would allow one to disambiguate
between two different files of the same name within an overal source
hierarchy: e.g. ./kernel/sys/cdrom.h and ./kernel/io/cam/cdrom.h.  Files that
are copies of these files into the exports or obj hierarchies would still
have the same name in their ident string with which they were checked in.

Another, separate, useful feature would be a compiler flag to list the full
pathname of each file accessed.  I remember seeing a flag like this for OSF's
version of GCC and it came in handy once for tracking down why something
worked at OSF and didn't work here.  The cpp -M flag comes close, but under
ODE one would like the same assurance for the source files, the compiler
phases and any files used by the linker.

 -- jmcg

Date Of Receipt: 	20-APR-1995 16:33:49.37
From: 	SMURF::WASTED::schloss "Mike Schloss usg  20-Apr-1995 1632"
To: 	buildhelp@DEC:.zko.wasted
CC: 	
Subj: 	kernel build question

I am trying to figure out the "right" way to short-circuit
a build (just build the pieces that I know have changed and
not redo the dependencies).  The AG Supplement lists a number
of commands which no longer work.  It also refers me to the
kernel makefile from which I am unable to extract the magic
incantation.  Can someone enlighten me?  Again, what I am
trying to do is minimize the time necessary to rebuild a
single kernel when I know that the only thing that has
changed is a single .c file.

Mike Schloss

Date Of Receipt: 	20-APR-1995 16:52:21.39
From: 	SMURF::WASTED::"[email protected]" "Brian Stevens  20-Apr-1995 1651"
To: 	[email protected]
CC: 	[email protected], [email protected]
Subj: 	Re: kernel build question
one thing that works is: 	

build BINARY_foo.o 

	warning, do:
		build MAKE_ARGS="foo_bar.o" BINARY_ 
	for files with _'s in there name

build SABLE_relink ( or other configuration )