<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>Tony, I'm not sure what your answer is below, but I commited #1  +#3.<BR>
 <BR>
 >> 1) import them m3-sys/m3cc/src/patches/openbsd<BR> >> 3) apply patches at build time<BR><BR>
Obvious major danger with the current code is of accidentally commiting the patched files.<BR>
Perhaps something like copying files into the output and using VPATH can remove that danger.<BR>
Or perhaps if the accident occurs, it is easily undone? I don't know.<BR>
 <BR>
 >> 2) perhaps use a vendor branch for the import <BR>
 <BR>
Could there be a vendor branch for "OpenBSD gcc" and then "mainline" is the merge of the various branches?<BR>
 <BR>
 <BR>
 - Jay<BR><BR>
<BLOCKQUOTE>
<HR id=EC_stopSpelling>
CC: m3devel@elegosoft.com<BR>From: hosking@cs.purdue.edu<BR>To: jayk123@hotmail.com<BR>Subject: Re: [M3devel] gcc/m3cc/cm3c for OpenBSD?<BR>Date: Tue, 27 May 2008 10:37:31 +0100<BR><BR>
<DIV><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV style="WORD-WRAP: break-word"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><BR class=EC_Apple-interchange-newline></SPAN></DIV></SPAN></DIV><BR>
<DIV>
<DIV>On May 19, 2008, at 1:47 PM, Jay wrote:</DIV><BR class=EC_Apple-interchange-newline>
<BLOCKQUOTE><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">What is the right way to handle these:<BR> <A href="http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/gcc/4.3/patches/" target=_blank>http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/gcc/4.3/patches/</A><BR>I imagine:<BR> 1) import them m3-sys/m3cc/src/patches/openbsd<BR> 2) perhaps use a vendor branch for the import<BR>   however they haven't changed in 14 months<BR>   and HOPEFULLY they get ported upstream</DIV></SPAN></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>Best this so later vendor upgrades don't confuse them with M3-related changes.</DIV><BR>
<BLOCKQUOTE><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"><BR> 3) apply patches at build time<BR><BR>Seems kind of bad, but I figure also too much to manage to checkin the patch results?<BR>I realize it stinks largely due to the risk of accidentally doing what is avoided.<BR>Maybe there is like "VPATH" and the to-be-patched files can be copied in the output<BR>directory and patched there?<BR><BR> They aren't all needed, by far, but definitely some of them are needed.<BR> <BR> not needed, roughly:<BR>    *objc*, *ada*, *lib*<BR><BR> needed, roughly:<SPAN class=EC_Apple-converted-space> </SPAN><BR>  *config*<SPAN class=EC_Apple-converted-space> </SPAN><BR><BR> unclear:<BR>  all the NULL to (void*) 0 diffs, which are a lot of it<BR><BR> I kinda'thunk:<BR>  #ifdef __cplusplus<BR>  #define NULL 0 /* would perhaps need patch, depending on what calling conventions<BR>  do with parameters and return values smaller than a word */<SPAN class=EC_Apple-converted-space> </SPAN><BR>  #else<BR>  #define NULL ((void*) 0) /* no need for patch */<SPAN class=EC_Apple-converted-space> </SPAN><BR>  #endif<BR><BR>in particular because in C++ a cast from void* to another* is needed, but not in C.<BR><BR>In fact I see this on OpenBSD:<BR><BR> #ifndef NULL<BR> #ifdef  __GNUG__<BR> #define NULL    __null<BR> #else<BR> #define NULL    0L<BR> #endif<BR><BR>Similar question for the AMD64_NT gcc patches, though these are newer, apparently<BR>still need testing, and since they are new, more hope they will go upstream.<BR>I don't know why the OpenBSD patches linger, I didn't ask.<BR><BR>I'll proceed as my suggest takes but presumably won't be read to commit<BR>  till after broader judgement/consensus rendered.<BR><BR>  - Jay<BR></DIV></SPAN></BLOCKQUOTE></DIV><BR></BLOCKQUOTE></body>
</html>