All --
> Since we are so early in the game, I'm not sure if it really matters whether
> we keep the version information or not. Does anyone have a problem with me
> deleting the header files and readding them under include/parrot/. or is the
> general concensus moving the RCS files?
Rather than do it via patch submission, I'd be happy to go in and make
the changes now that I have write access. Have there been any objections
to this process:
$ cvs -q upd -AdP
$ mkdir -p include/parrot
$ cvs add include
$ cvs add include/parrot
$ for hdr in *.h; do
cp -a $hdr include/parrot
cvs add /include/parrot/$hdr
cvs remove -f $hdr
done
$ cvs commit -m 'gnp: Moved all header files to include/parrot'
With the appropriate modification to Makefile.in as well (diff
attached)? I don't remember seeing anyone particularly upset by it.
[[ UPDATE: REALLY ATTACHED THIS TIME ]]
If not, I'd be happy to do it. It'll take just a few minutes...
> Also, would anyone like to see a standard C comment header that includes the
> RCS information added to each file?
I would definitely like to see something like
# $Revision: $
at a minimum.
Regards,
-- Gregor
_____________________________________________________________________
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \
Gregor N. Purdy [EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
8080 Beckett Center Drive #203 513-860-3570 vox
West Chester, OH 45069 513-860-3579 fax
\_____________________________________________________________________/
Index: Makefile.in
===================================================================
RCS file: /home/perlcvs/parrot/Makefile.in,v
retrieving revision 1.2
diff -u -r1.2 Makefile.in
--- Makefile.in 2001/09/14 14:08:00 1.2
+++ Makefile.in 2001/09/15 00:01:36
@@ -4,7 +4,7 @@
O_FILES = global_setup$(O) interpreter$(O) parrot$(O) register$(O) basic_opcodes$(O) memory$(O) bytecode$(O) string$(O) strnative$(O)
-C_FLAGS = ${ccflags} -I..
+C_FLAGS = ${ccflags} -I./include
C_LIBS = ${libs}
