Ivan Zhakov wrote:
> On 12/23/05, Branko Čibej <brane@xbc.nu> wrote:
>
>> Ivan Zhakov wrote:
>>
>>> On 12/13/05, Branko Čibej <brane@xbc.nu> wrote:
>>>
>>>
>>>> Ivan Zhakov wrote:
>>>>
>>>>
>>>>> On 12/5/05, Ivan Zhakov <chemodax@gmail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Hi!
>>>>>> 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
>> import libraries.
>>
> I am ok to follow APR naming libraries, but in this case we have one
> problem: now we specify library name already with 'lib' in build.conf,
> so we need strip it for static libraries or change build.conf and add
> 'lib' prefix for dll and *nix libs. What is better?
>
No, we don't have to do that. It's enough to teach the Windows generator
to treat those libsvn_foo specially.
>> 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,
>> isn't it?
>>
> Hmm, I don't think that it is right. Because such switch not
> transparent for people who linked static libraries.
>
It doesn't have to be transparent, IMHO. Windows is a slightly special
case, and if we implement this in a minor release (say, 1.4), that's
good enough for me. It's not as if we're changing the ABI for existing
binaries.
>>> 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
>> libraries.
>>
> I didn't found flag that distinguishs test. Or may be you meant
> "install = test" ?
>
Yes.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 23 15:17:22 2006