[M3devel] gcc/m3cc/cm3c for OpenBSD?

[Jay]

What is the right way to handle these: http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/gcc/4.3/patches/
I imagine: 1) import them m3-sys/m3cc/src/patches/openbsd 2) perhaps use a vendor branch for the import   however they haven't changed in 14 months   and HOPEFULLY they get ported upstream 3) apply patches at build time
Seems kind of bad, but I figure also too much to manage to checkin the patch results?I realize it stinks largely due to the risk of accidentally doing what is avoided.Maybe there is like "VPATH" and the to-be-patched files can be copied in the outputdirectory and patched there?
 They aren't all needed, by far, but definitely some of them are needed.
 
 not needed, roughly:    *objc*, *ada*, *lib*
 needed, roughly:   *config* 
 unclear:  all the NULL to (void*) 0 diffs, which are a lot of it
 I kinda'thunk:  #ifdef __cplusplus  #define NULL 0 /* would perhaps need patch, depending on what calling conventions
  do with parameters and return values smaller than a word */   #else  #define NULL ((void*) 0) /* no need for patch */   #endif
in particular because in C++ a cast from void* to another* is needed, but not in C.
In fact I see this on OpenBSD:
 #ifndef NULL #ifdef  __GNUG__ #define NULL    __null #else #define NULL    0L #endif
Similar question for the AMD64_NT gcc patches, though these are newer, apparentlystill need testing, and since they are new, more hope they will go upstream.I don't know why the OpenBSD patches linger, I didn't ask.
I'll proceed as my suggest takes but presumably won't be read to commit  till after broader judgement/consensus rendered.
  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080519/f11abfc9/attachment-0001.html>