> >> 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.
_______________________________________________
Mailing list: https://launchpad.net/~coapp-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~coapp-developers
More help : https://help.launchpad.net/ListHelp
