All of lore.kernel.org
 help / color / mirror / Atom feed
From: Larry McVoy <lm@bitmover.com>
To: "Randy.Dunlap" <rddunlap@osdl.org>
Cc: rmoser <mlmoser@comcast.net>, linux-kernel@vger.kernel.org
Subject: Re: Kernel source tree splitting
Date: Wed, 30 Apr 2003 17:52:24 -0700	[thread overview]
Message-ID: <20030501005224.GA8676@work.bitmover.com> (raw)
In-Reply-To: <20030430172102.69e13ce9.rddunlap@osdl.org>

It would be *really* cool if the Makefile dependencies actually worked.
It's a very little known fact but if you are in an RCS or SCCS (and BK
looks like SCCS to make) source tree and the files are not checked out,
you can just say

	make

and make will look for a makefile, if there isn't one but there is a 
SCCS/s.[Mm]akefile it will check it out, look at the dependencies and start
checking those out and keep doing it to satisfy the target.

It's a really pleasant way to work, the "make clobber" target "cleans"
all the source so it isn't checked out, the directory is nice and empty.
This makes it easy to see stuff you still need to check in or think about.
It's definitely an old timer way of working, I'm pretty sure that the
original Unix was done this way but just because it is old doesn't mean
it is bad.  Opinions differ on that :)

Here's a make in a cleaned BK source tree:

$ lf
Notes/  gnu/  ide/   port/  tmp/       utils/  win32/
SCCS/   gui/  mdbm/  t/     tomcrypt/  web/    zlib/
$ make p
get   SCCS/s.Makefile
Makefile 1.326: 684 lines
make CFLAGS="-g -O2 -Wall -Wno-parentheses -Wno-char-subscripts -Wno-format-y2k -Wstrict-prototypes " all
get   SCCS/s.abort.c
abort.c 1.11: 157 lines
get   SCCS/s.unix.h
unix.h 1.48: 79 lines
get   SCCS/s.bkd.h
bkd.h 1.68: 157 lines
get   SCCS/s.lib_tcp.h
lib_tcp.h 1.12: 21 lines
get   SCCS/s.logging.h
logging.h 1.10: 80 lines
get   mdbm/SCCS/s.common.h
mdbm/common.h 1.6: 111 lines
get   mdbm/SCCS/s.mdbm.h
mdbm/mdbm.h 1.11: 426 lines
get   mdbm/SCCS/s.tune.h
mdbm/tune.h 1.3: 66 lines
get   SCCS/s.mmap.h
mmap.h 1.5: 30 lines
get   SCCS/s.purify.h
purify.h 1.31: 114 lines
get   SCCS/s.range.h
range.h 1.18: 42 lines
get   SCCS/s.rcs.h
rcs.h 1.6: 60 lines
get   SCCS/s.liblines.h
liblines.h 1.5: 81 lines
get   SCCS/s.resolve.h
resolve.h 1.36: 178 lines
get   SCCS/s.sccs.h
sccs.h 1.497: 1171 lines
get   SCCS/s.system.h
system.h 1.55: 157 lines
get   tomcrypt/SCCS/s.mpi-config.h
tomcrypt/mpi-config.h 1.1: 87 lines
get   tomcrypt/SCCS/s.mpi.h
tomcrypt/mpi.h 1.1: 225 lines
get   tomcrypt/SCCS/s.mycrypt_cfg.h
tomcrypt/mycrypt_cfg.h 1.4: 174 lines
get   tomcrypt/SCCS/s.mpi-types.h
tomcrypt/mpi-types.h 1.1: 19 lines
get   tomcrypt/SCCS/s.mycrypt.h
tomcrypt/mycrypt.h 1.2: 913 lines
get   SCCS/s.zgets.h
zgets.h 1.5: 23 lines
get   zlib/SCCS/s.deflate.h
zlib/deflate.h 1.4: 318 lines
get   zlib/SCCS/s.infblock.h
zlib/infblock.h 1.4: 39 lines
get   zlib/SCCS/s.infcodes.h
zlib/infcodes.h 1.4: 27 lines
get   zlib/SCCS/s.inffast.h
zlib/inffast.h 1.4: 17 lines
get   zlib/SCCS/s.inffixed.h
zlib/inffixed.h 1.2: 151 lines
get   zlib/SCCS/s.inftrees.h
zlib/inftrees.h 1.4: 58 lines
get   zlib/SCCS/s.infutil.h
zlib/infutil.h 1.4: 98 lines
get   zlib/SCCS/s.trees.h
zlib/trees.h 1.2: 128 lines
get   zlib/SCCS/s.zconf.h
zlib/zconf.h 1.4: 279 lines
get   zlib/SCCS/s.zlib.h
zlib/zlib.h 1.4: 893 lines
get   zlib/SCCS/s.zutil.h
zlib/zutil.h 1.3: 220 lines
cc -g -O2 -Wall -Wno-parentheses -Wno-char-subscripts -Wno-format-y2k -Wstrict-prototypes  -Izlib -Imdbm -c abort.c -o abort.o
get   SCCS/s.adler32.c
adler32.c 1.15: 144 lines
cc -g -O2 -Wall -Wno-parentheses -Wno-char-subscripts -Wno-format-y2k -Wstrict-prototypes  -Izlib -Imdbm -c adler32.c -o adler32.o
get   SCCS/s.admin.c
admin.c 1.122: 453 lines
cc -g -O2 -Wall -Wno-parentheses -Wno-char-subscripts -Wno-format-y2k -Wstrict-prototypes  -Izlib -Imdbm -c admin.c -o admin.o
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

  parent reply	other threads:[~2003-05-01  0:40 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-30 23:46 Kernel source tree splitting rmoser
2003-05-01  0:21 ` Randy.Dunlap
2003-05-01  0:44   ` rmoser
2003-05-01  2:51     ` Randy.Dunlap
2003-05-01 10:13       ` rmoser
2003-05-01  0:52   ` Larry McVoy [this message]
2003-05-01  1:00     ` rmoser
2003-05-01 17:28     ` James H. Cloos Jr.
2003-05-01  4:10   ` Martin J. Bligh
2003-05-01  6:14     ` Ed Sweetman
2003-05-01  6:14       ` Peter Riocreux
2003-05-02  0:09   ` Randy.Dunlap
2003-05-02  0:41     ` rmoser
  -- strict thread matches above, loose matches on Subject: below --
2003-05-01 11:54 Chuck Ebbert
2003-05-01 14:06 ` Martin J. Bligh
2003-05-01 14:20   ` Willy TARREAU
2003-05-01 14:35     ` Martin J. Bligh
2003-05-01 14:43       ` Willy TARREAU
2003-05-01 15:01       ` Larry McVoy
2003-05-01 15:11         ` Martin J. Bligh
2003-05-01 17:22 ` Balram Adlakha
2003-05-01 17:28   ` Ben Greear
2003-05-01 20:03     ` John Bradford
2003-05-01 16:00 Chuck Ebbert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030501005224.GA8676@work.bitmover.com \
    --to=lm@bitmover.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mlmoser@comcast.net \
    --cc=rddunlap@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.