Ivan Zhakov wrote:
> On 12/13/05, Branko Čibej <firstname.lastname@example.org> wrote:
>> Ivan Zhakov wrote:
>>> On 12/5/05, Ivan Zhakov <email@example.com> wrote:
>>>> I am working on building Windows Subversion DLLs (issue 1627). When
>>>> this work will be finished, we cannot build some tests because they
>>>> call internal functions that will not be exported by DLLs.
>>>> So I am going to commit Russell Yanofsky's patch that introduce new
>>>> build.conf option "sourcelibs". Libraries listed in this option will
>>>> be linked directly by sources.
>> I wish you hadn't done this.
>> As I said in several other posts now and in the past, I expect the
>> Windows DLLs to be build by a simple relink of the static libraries --
>> *not* as a complete separate target (or, worse MSVC "configuration").
BTW, sorry if this sounded a bit bossy... I'm offline most of the time
lately, and I get a bit nervous without my fix. :)
>> If we do this, then we can simply link the unit tests with the static
>> libs, and link the command-line utilities with the DLLs -- the tests
>> will be valid since both variants of the library contain identical code.
>> I think this is much better than complicating the build system with
>> source vs. library link optins, and we _do_ want to build both the
>> static and the dynamic libraries.
> Ok, I understand and agree with arguments. So I'll revert my commit.
> Now I have another roadmap to create DLL:
> 1. Remove dependency to ctype from libsvn_client by creating
> svn_xml_is_xml_name_valid function in libsvn_subr and use it for
> validating prop name.
> 2. Revert my "sourcelibs" change
> 3. Introduce new build.conf option 'msvc-dll', for targets with this
> options generate project with name like libsvn_client_dll which links
> to original lib and export all symbols. This is partially completed.
Let's follow APR's lead in naming the libraries. APR has
apr.lib, aprutil.lib, apriconv.lib -- static libraries
libapr.dll/lib libaprutil.dll/lib libapriconv.dll/lib -- DLLs and
Yes, I know that people who linked with our current static libraries
suddenly switch to the DLLs, but then, that's what we want by default,
> 4. Add new gen-make.py option to specify link our executables
> dynamicly (to DLLs) or staticly. For tests add new build.conf like
> 'msvc-force-static' for forcing linking it to static libs.
I believe you can do without the new flag, as there's already a flag
that identifies unit tests. Just link all unit tests with the static
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sun Dec 25 01:54:49 2005