[Gc] RE: VC++ build files

DrPizza DrPizza at quiscalusmexicanus.org
Mon Jun 30 17:54:34 PDT 2008


> The current Windows Makefiles are not in great shape.
> 
> The problem with project files is that they're a single platform,
> completely nonportable, solution.  They tend to be hard to edit for
> anyone not on a Windows platform.  And we've been short a volunteer to
> maintain them.  Certainly updated versions would be appreciated, but
> they tend to deteriorate to a basis for a do-it-yourself project in the
> absence of a maintainer.
I think all of that is true of the nmake Makefiles too, isn't it?  And nmake has the disadvantage that no-one really uses it anyway these days.  My feeling was that at least by having a project file, it would be somewhat more approachable.

> > All builds:    GC_THREADS,
> >                GC_WIN32_THREADS,
> These first two are redundant, at least for recent versions.  One
> should be enough.
OK.

> >                GC_BUILD,
> >                ALL_INTERIOR_POINTERS,
> >                __STDC__
> Already defined by compiler?
No, at least not according to the documentation. __STDC__ is only defined by VC++ when the MS extensions are disabled; however, I believe the MS extensions are mandatory if one wants to parse the Windows headers.

> > DLL builds:    GC_DLL
> > Static builds: GC_NOT_DLL,
> >                THREAD_LOCAL_ALLOC
> That's an interesting and unfortunate tradeoff.  I would expect
> THREAD_LOCAL_ALLOC to be appreciably faster.  But it doesn't work with
> DllMain-based implicit thread registration.  If you know that all
> clients will be using the normal portable GC interface, I'd recommend
> turning on THREAD_LOCAL_ALLOC for DLL builds, though that may not have
> been well tested.
I wasn't sure about this one.  It felt safer to me to use DllMain-based registration, just because it feels more "automatic"; you link against the library and it does (more or less) the Right Thing.  Is there any kind of a benchmark that would make a case one way or the other?

> > My question is, are these reasonable?  The project files in
> > CVS also define SAVE_CALL_COUNT=8.  If I define that then I
> > get crashes inside GC_save_callers; the memcpy (BCOPY) is
> > passed bad parameters and crashes.  Don't know why.
> Me neither.  Note that some of the related code is in msvc_dbg.c.
Yes, I saw that; once I can figure out why it's crashing I think updating that to work on x64 should be easy to do.

> > The project structure I'm using is quite different from that
> > of the projects that are in CVS.  Instead of a project each
> > for static/DLL I have one project with multiple
> > configurations.  I find this makes organization a little easier.
> Sounds good to me.
OK.  IS the best way to proceed to figure out how to generate a patch and then send it to the mailing list?

Peter



More information about the Gc mailing list