coapp-developers team mailing list archive

[Trent Nelson <trent@xxxxxxxxxxxxx>]

> >> What kind of build options are we talking about?
> >> For some projects this might be a problem, but I think there are
> >> enough projects for which this will not be a problem.
> >
> > Optimization flags, availability of .pdb debugging symbols (e.g.
> > equivalent of foo-debug linux/bsd distro package variants), etc.
> 
> I'm not sure I understand the problem.
> Different projects might use different optimizations, so what?

Bill definitely has a valid point.  You'd be surprised at what kind of crazy builds you can end up with for some open source projects when you attempt to build them on Windows with their out-of-the-box settings (assuming their release even compiles on Windows; OpenSSL has the odd release every now and then that just flat out doesn't compile out-of-the-box on Windows).

I remember how much trouble I had trying to get the out-of-the-box Windows builds of BerkeleyDB and TclTk to work with Python.  BerkeleyDB was using the most esoteric compiler and linker flags that I've ever come across, and the resulting binary, especially in 64-bit builds, just flat out wasn't suitable for linking against.  I mean, it would link, 'cause the API was compatible at the source level, but you'd get the strangest crashes as soon as you attempted to call anything in that library.  TclTk wasn't much better -- and SQLite was problematic too, now that I think of it.

Python's solution was to set up an 'external' svn repo where we import the entire project's source code.  Then we'd do one of two things:

a) For smaller, well-contained projects like SQLite, we'd just completely ignore the .vcproj files (or Makefiles or .dsp or whatever) it shipped with.  Instead, we'd add a new 'sqlite' project to our solution, and manually add all the source files as if it were any other Python component.  This meant that it would get built with exactly the same compiler and linker settings as everything else (and also allowed PGO optimisations to span cross-project function call boundaries).  This worked wonderfully well.


b) For the bigger things like BerkeleyDB and TclTk, we'd end up hacking their vcproj/dsp/whatever files until the project built in a sensible fashion and interop'd with us cleanly.

I'd like CoApp to make this sort of messing about a thing of the past.  For us to support the latter option, I think we'd need to standardise a common set of debug/release compiler/linker settings that projects can attempt to adhere to (or we adhere to in the shallow fork of their project).

(It would also be useful to document what sort of settings are going to seriously break binary compatibility.  None of the projects I came across needed any of their crazy settings, nor was it obvious why they'd even used that setting in the first place -- I put it down to Windows unfamiliarity.  And/or cosmic rays.)


	Trent.