Re: Goo porting questions

[Jonathan Bachrach <jrb@xxxxxxxxxx>]

Chris Double <chris@double.co.nz> writes:

> I've been working some more on the Win32 MSVC port and I've got a
> couple of questions/comments.
> 
> Currently I'm not using 'inline' functions with MSVC because I get
> linker errors like the following:
> 
> %lock.obj : error LNK2001: unresolved external symbol _allocate
> math.obj : error LNK2001: unresolved external symbol _YPfi2f
> math.obj : error LNK2001: unresolved external symbol _YPfE
> math.obj : error LNK2001: unresolved external symbol _YPfL
> math.obj : error LNK2001: unresolved external symbol _YPfA
> math.obj : error LNK2001: unresolved external symbol _YPf_
> [...snip...]
> 
> This is caused by functions defined in grt.c as inline. In MSVC all
> inline functions must exist in a header file included by the .c file
> that uses them, otherwise they'll not be linked at all as they don't
> 'exist' having been inlined in the module where they live (grt.c).
> 
> What's a good way of working around this? Move the INLINE functions in
> grt.c to a header file? Don't make them inline? 
>
> In the meantime I'm creating a LOCAL_INLINE which is 'inline' for gcc
> and nothing for MSVC and I'll modify the grt.c inline functions to use
> this. The inline functions in grt.h will remain as INLINE. Maybe not a
> good long term solution as it causes a lot of functions that could be
> inline to not be inlined. I'd like to opt for moving them into grt.h
> or another header file perhaps? Thoughts?

this calls for a reorganization of INLINE functions.  all the flo
routines can be moved to grt.h and other ones could either be marked
LOCAL_INLINE or moved to a private header if their not being inlined
adversely performance.

> I could leave inline out completely for MSVC but it makes Goo a bit
> slower.

no this is too heavy handed.  the bigger problem is that some
primitive functions in boot are defined INLINE and do not occur in a
header and it would be a bit more complicated to produce a header file
c file produced.  i do now have a mechanism for doing my own inlining
of ast but this is a bit slower than the c compiler at this stage of
goo's life so i would like to know if this is indeed a problem.

> My other question is what to do about generating makefiles for
> MSVC. Currently I see the makefile is generated by 'generate-makefile'
> in g2c.goo and it uses Gnu makefiles.
> 
> What's a good way of adding support for generating makefiles for
> Microsoft make?  Or for other build systems (I'd like to get support
> going for Symbian operating systems for example which uses their own
> make type system).
> 
> Is it worth adding some sort of c-backend identifier that things like
> generate-makefile can dispatch on? Or does that add too much knowledge
> to the Goo code about the build system? Other ideas?

i would hate to have target specific builds as this compromises our
ability to produce one set of c-files / makefiles per platform.  of
course this depends on a gnu set up on all platforms (which was the
previous assumption).  given that this isn't possible, would it be
possible to either produce all makefiles or perhaps write a program
that can translate a platform independent makefile (say using sexprs)
producing other platform specific makefiles?  i'm open to suggestions
(esp ones that are simple).

jonathan