[Gc] RE: VC++ build files
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.
> > 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?
More information about the Gc