[vorbis-dev] Re: win32sdk-1.0.1
dimitry at andric.com
Fri Oct 3 15:36:27 PDT 2003
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?
<p>> I assume the 'd' extension is for the debugging versions.
<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:
- 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...
Size: 184 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/vorbis-dev/attachments/20031004/fab8dcfc/part-0001.pgp
More information about the Vorbis-dev