[vorbis-dev] Re: win32sdk-1.0.1

[Dimitry Andric]

On 2003-10-03 at 02:01:08 Ralph Giles wrote:

>> Therefore, since the vorbis libs need the ogg libs, there is already
>> an inconsistency in the runtime libraries used.

> Aha. Thanks for the explanation.

Note that this can be fixed in a simple manner, as John Edwards
already posted. However, in such a case as this, you determine the
specific libraries that the user can link with.

<p>> Yikes. Do 7.0 and 7.1 still have single-threaded versions of the runtime?

Yes.

<p>> I assume the 'd' extension is for the debugging versions.

Yes.

<p>> That's 12 permutations.

I've got a project workspace file here which contains the following
subproject permutations (this is just for VC++ 6.0!):

##   project name              produces         linked runtime
--   -----------------------   --------------   -----------------
01   lib_ogg_d_md.dsp          ogg.dll          multithreaded DLL
02 * lib_ogg_d_ml.dsp          ogg.dll          singlethreaded
03   lib_ogg_d_mt.dsp          ogg.dll          multithreaded
04   lib_ogg_s_md.dsp          ogg.lib          multithreaded DLL
05   lib_ogg_s_ml.dsp          ogg.lib          singlethreaded
06   lib_ogg_s_mt.dsp          ogg.lib          multithreaded
07   lib_vorbisenc_d_md.dsp    vorbisenc.dll    multithreaded DLL
08 * lib_vorbisenc_d_ml.dsp    vorbisenc.dll    singlethreaded
09   lib_vorbisenc_d_mt.dsp    vorbisenc.dll    multithreaded
10   lib_vorbisenc_s_md.dsp    vorbisenc.lib    multithreaded DLL
11   lib_vorbisenc_s_ml.dsp    vorbisenc.lib    singlethreaded
12   lib_vorbisenc_s_mt.dsp    vorbisenc.lib    multithreaded
13   lib_vorbisfile_d_md.dsp   vorbisfile.dll   multithreaded DLL
14 * lib_vorbisfile_d_ml.dsp   vorbisfile.dll   singlethreaded
15   lib_vorbisfile_d_mt.dsp   vorbisfile.dll   multithreaded
16   lib_vorbisfile_s_md.dsp   vorbisfile.lib   multithreaded DLL
17   lib_vorbisfile_s_ml.dsp   vorbisfile.lib   singlethreaded
18   lib_vorbisfile_s_mt.dsp   vorbisfile.lib   multithreaded
19   lib_vorbis_d_md.dsp       vorbis.dll       multithreaded DLL
20 * lib_vorbis_d_ml.dsp       vorbis.dll       singlethreaded
21   lib_vorbis_d_mt.dsp       vorbis.dll       multithreaded
22   lib_vorbis_s_md.dsp       vorbis.lib       multithreaded DLL
23   lib_vorbis_s_ml.dsp       vorbis.lib       singlethreaded
24   lib_vorbis_s_mt.dsp       vorbis.lib       multithreaded

(The subprojects marked with * are not very likely to be used in a
realistic situation, so you're left with 20 combinations. Note also
that I left out the Tremor subprojects, and a 'vorbistools' project
which I use internally.)

Then you just add VS.NET 2002 and 2003, giving 60 combinations. :)

Here are for reference my current VC6 projects (including source),
which use subprojects as described above:

 http://www.andric.com/vorbis/vorbis-1_0-vc6-workspace.zip  (~1.4 MB)
 http://www.andric.com/vorbis/vorbis-head-vc6-workspace.zip (~1.8 MB)

<p>> Even if we ship three sets of binaries, it sounds like the sdk
> should include source and a project file for each version.

Yes, I agree this SDK should come with source. That's so nice about
open source projects, isn't it? :) And indeed, ideally you should have
different project files for each version of Visual C++, because the
import facilities in VS.NET are not very good, IMHO.

In my own situation, I just choose the correct version of the ogg,
vorbis and optionally vorbisfile and vorbisenc library subprojects
from the above list, and include them as 'dependencies' in a VC++ 6
workspace. In this way, they automatically get built whenever
necessary (which should only be the first time, of course).

If you really want to deliver binaries, you should probably have
different versions for each Visual C++ variant.

<p>> Is there a best-practices for this sort of thing? I can't imagine
> this sort of developer support is unusual.

Best practice is of course to deliver binaries for each different
compiler. I'm sure this is the same for Linux, for instance, where you
can't just mix and match different major versions of gcc and/or glibc
in your projects. Many times I see developers simply releasing
completely statically linked versions of their applications, to
prevent any problems with inconsistent shared libraries and/or ABIs.

A possible scenario is to produce:

- Static libraries compiled with each different version of VC++,
  preferably in the flavours:
  1) singlethreaded-static-c-runtime
  2) multithreaded-static-c-runtime
  3) multithreaded-dynamic-c-runtime
- DLLs compiled with each different version of VC++, but in this case
  you probably only need the "multithreaded-dynamic-c-runtime"
  flavour. If you're using DLL's anyway, it's best to simply use the
  DLL version of the C runtime too.

I'm afraid there isn't a one-size-fits-all solution... :(

-------------- next part --------------
A non-text attachment was scrubbed...
Name: part
Type: application/pgp-signature
Size: 184 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/vorbis-dev/attachments/20031004/fab8dcfc/part-0001.pgp