You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ivan Zhakov <ch...@gmail.com> on 2006/01/23 13:45:14 UTC
Re: [PATCH] Introduce new build.conf option "sourcelibs"
On 12/23/05, Branko Čibej <br...@xbc.nu> wrote:
> Ivan Zhakov wrote:
> > On 12/13/05, Branko Čibej <br...@xbc.nu> wrote:
> >
> >> Ivan Zhakov wrote:
> >>
> >>> On 12/5/05, Ivan Zhakov <ch...@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?
>
> 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.
>
> > 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" ?
--
Ivan Zhakov
Re: [PATCH] Introduce new build.conf option "sourcelibs"
Posted by Branko Čibej <br...@xbc.nu>.
Ivan Zhakov wrote:
> On 1/23/06, Branko Čibej <br...@xbc.nu> wrote:
>
>> Ivan Zhakov wrote:
>>
>>> On 1/23/06, Branko Čibej <br...@xbc.nu> wrote:
>>>
>>>
>>>>>> 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.
>>>>
>>>>
>>> It is easy to say "teach the Windows generator" :) Sorry, I am not
>>> expert in Windows generator, might be because it is overburden. Could
>>> you give me some points how to and where do this?
>>>
>>>
>> Oof, I'd have to dig in myself. And "overburden" is an understatement. :)
>>
>> I'll try to find time to look into this soon.
>>
> Wow, it would be great! I consider that Windows DLLs is important stuff.
> So meanwhile I concentrate on other parts of this tasks: factor out
> svn_xml_is_xml_name_valid() and teach extractor.py ignore non windows
> exports.
>
> If you interesting I can send my current status of generator.
>
Nah, just check in whatever you think is ready.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Introduce new build.conf option "sourcelibs"
Posted by Ivan Zhakov <ch...@gmail.com>.
On 1/23/06, Branko Čibej <br...@xbc.nu> wrote:
> Ivan Zhakov wrote:
> > On 1/23/06, Branko Čibej <br...@xbc.nu> wrote:
> >
> >>>> 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.
> >>
> > It is easy to say "teach the Windows generator" :) Sorry, I am not
> > expert in Windows generator, might be because it is overburden. Could
> > you give me some points how to and where do this?
> >
> Oof, I'd have to dig in myself. And "overburden" is an understatement. :)
>
> I'll try to find time to look into this soon.
Wow, it would be great! I consider that Windows DLLs is important stuff.
So meanwhile I concentrate on other parts of this tasks: factor out
svn_xml_is_xml_name_valid() and teach extractor.py ignore non windows
exports.
If you interesting I can send my current status of generator.
--
Ivan Zhakov
Re: [PATCH] Introduce new build.conf option "sourcelibs"
Posted by Branko Čibej <br...@xbc.nu>.
Ivan Zhakov wrote:
> On 1/23/06, Branko Čibej <br...@xbc.nu> wrote:
>
>>>> 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.
>>
> It is easy to say "teach the Windows generator" :) Sorry, I am not
> expert in Windows generator, might be because it is overburden. Could
> you give me some points how to and where do this?
>
Oof, I'd have to dig in myself. And "overburden" is an understatement. :)
I'll try to find time to look into this soon.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Introduce new build.conf option "sourcelibs"
Posted by Ivan Zhakov <ch...@gmail.com>.
On 1/23/06, Branko Čibej <br...@xbc.nu> wrote:
> >> 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.
It is easy to say "teach the Windows generator" :) Sorry, I am not
expert in Windows generator, might be because it is overburden. Could
you give me some points how to and where do this?
--
Ivan Zhakov
Re: [PATCH] Introduce new build.conf option "sourcelibs"
Posted by Branko Čibej <br...@xbc.nu>.
Ivan Zhakov wrote:
> On 12/23/05, Branko Čibej <br...@xbc.nu> wrote:
>
>> Ivan Zhakov wrote:
>>
>>> On 12/13/05, Branko Čibej <br...@xbc.nu> wrote:
>>>
>>>
>>>> Ivan Zhakov wrote:
>>>>
>>>>
>>>>> On 12/5/05, Ivan Zhakov <ch...@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