This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[RFC/PATCH] make "make install" play nicely in CVS trees



     Hi everyone,

  When I'm building gcc, I use a --prefix that points into the CVS tree that
I'm working on, as we like to keep a binary copy of our toolchain under CVS.
I imagine I'm not the only person who works this way; it seems a pretty
sensible scheme to me.

  Unfortunately, when you do "make install", it deletes and recreates the
fixincluded headers dir as part of making the "install-include-dir" target.
This has the effect of trashing the CVS metadata for that subtree; this
means that any changes in the fixincludes headers won't be picked up and
stored in CVS until you remember to regenerate the metadata by blowing away
the directory and rebuilding it with "cvs update -d".  Which is a minor pain
because cvs moves the new headers out of the way and then you have to rename
them all back, or copy them somewhere else beforehand and put them back
after.  It's hardly the end of the world, but it's an inconvenience, and I
think it can be easily sorted without breaking anything.

  This simple patch changes the method of creating the dir for the
fixinclude headers.  Instead of rm -rf'ing and then mkdir'ing the directory,
we create it only if it doesn't already exist, then iterate through it and
rm everything that isn't called "CVS".

Questions:
----------

#1:  The reason I've put RFC in the subject is because I'm not sure that
looking out for a hard-coded directory name is necessarily the best
approach.  Maybe we should only be deleting files that match something we're
about to install?  Maybe we should only delete .h files?  Maybe it would be
reasonable to delete ordinary files but leave subdirectories alone?  These
all seem like reasonable alternative approaches to me, and I can't really
find any great reasons to prefer one over the other.  What does anyone else
think?  

#2:  I can never remember whether I should send the patch for the generated
file as well as the .in file; there's nothing at 
http://gcc.gnu.org/contribute.html
nor
http://gcc.gnu.org/codingconventions.html
to let me know.  Do I just leave it to whichever maintainer does the actual
checkin to regenerate?

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....


2004-03-25  Dave Korn  <dk@artimi.com>

	* Makefile.in: Create include install directory without destroying
any
	CVS metadata subdirectory that might have been placed there.     

Index: Makefile.in
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/Makefile.in,v
retrieving revision 1.1266
diff -c -3 -p -r1.1266 Makefile.in
*** Makefile.in	24 Mar 2004 18:03:15 -0000	1.1266
--- Makefile.in	25 Mar 2004 13:43:51 -0000
*************** install-headers: $(INSTALL_HEADERS_DIR)
*** 3055,3062 ****
  
  # Create or recreate the gcc private include file directory.
  install-include-dir: installdirs
! 	-rm -rf $(DESTDIR)$(libsubdir)/include
! 	mkdir $(DESTDIR)$(libsubdir)/include
  	-chmod a+rx $(DESTDIR)$(libsubdir)/include
  
  # Install the include directory using tar.
--- 3055,3070 ----
  
  # Create or recreate the gcc private include file directory.
  install-include-dir: installdirs
! 	if [ -d $(libsubdir)/include ] ; then \
! 		true ; \
! 	else \
! 		mkdir $(libsubdir)/include ; \
! 	fi;
! 	for i in $(libsubdir)/include/* ; do \
! 		if [ "$$i" != "$(libsubdir)/include/CVS" ] ; then \
! 			echo -rm -rf $$i; \
! 		fi; \
! 	done;
  	-chmod a+rx $(DESTDIR)$(libsubdir)/include
  
  # Install the include directory using tar.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]