Re: Reapply patch lost during recent "blind import" of libtool

[Alexandre Oliva <aoliva at redhat dot com>]

On Apr 12, 2001, Mark Mitchell <mark@codesourcery.com> wrote:

>>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:
Alexandre> Well, if folks agree with this policy, I'd be happy to
Alexandre> post a patch myself :-)

> Do it.

Yes, sir! :-)

Ok to install?

Index: codingconventions.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/codingconventions.html,v
retrieving revision 1.3
diff -u -p -r1.3 codingconventions.html
--- codingconventions.html 2000/11/11 09:10:38 1.3
+++ codingconventions.html 2001/04/12 05:02:14
@@ -117,5 +117,60 @@ against <code>error_mark_node</code> rat
 <code>TREE_CODE</code> against <code>ERROR_MARK</code>; see <a
 href="http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00792.html";>message</a>.</p>
 
+
+<h2>Upstream packages</h2>
+
+Some files and packages in the CVS tree are imported from elsewhere,
+and we want to minimize divergence from their upstream sources.  The
+following files should be updated only according to the rules set
+below:
+
+<ul>
+
+<li>config.guess, config.sub: The master copy of these files is at <a
+href="ftp://ftp.gnu.org/pub/gnu/config/";>ftp://ftp.gnu.org/pub/gnu/config</a>.
+Proposed changes should be e-mailed to <a
+href="mailto:config-patches@gnu.org";>config-patches@gnu.org</a>.  Only
+after the change makes it to the FTP site should the new files be
+installed in the GCC CVS tree, so that their version numbers remain
+meaningful and unique.  Don't install the patch, install the whole
+file.
+
+<li>ltconfig, ltmain.sh, libtool.m4, ltcf-c.sh, ltcf-cxx.sh,
+ltcf-gcj.sh: The master copy of these files is the CVS repository of
+<a href="http://www.gnu.org/software/libtool/libtool.html";>GNU
+libtool</a>.  Patches should be posted to <a
+href="mailto:libtool-patches@gnu.org";>libtool-patches@gnu.org</a>.
+Only after the change makes it to the libtool CVS tree should the new
+files be installed in the GCC CVS tree.  ltconfig and ltmain.sh are
+generated files from ltconfig.in and ltmain.in, respectively, so, when
+you post the patch, make sure you're patching the source file, not the
+generated one.  When you update these generated files in the GCC CVS
+tree, make sure they report the same timestamp and version number, and
+note this version number in the ChangeLog.
+
+<li>Top-level configure.in, configure, Makefile.in, config-ml.in,
+config.if and most other top-level shell-scripts: Please try to keep
+these files in sync with the corresponding files in the src repository
+at sources.redhat.com.  Some people hope to eventually merge these CVS
+trees into a single repository; keeping them in sync helps this goal.
+When you check in a patch to one of these files, please check it in
+the src tree too, or ask someone else with CVS write access there to
+do so.
+
+<li>fastjar: The master sources are at <a
+href="http://fastjar.sourceforge.net/";>fastjar.sourceforge.net</a>.
+Local patches should be sent upstream, but it's acceptable to check
+them in the GCC CVS tree before getting them installed in the master
+tree.
+
+<li>boehm-gc: The master sources are at <a
+href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/";>www.hpl.hp.com/personal/Hans_Boehm/gc</a>.
+Patches should be sent to <a href="boehm@acm.org">boehm@acm.org</a>,
+but it's acceptable to check them in the GCC CVS tree before getting
+them installed in the master tree.
+
+</ul>
+
 </body>
 </html>

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me