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?
>
> 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
Received on Mon Jan 23 14:56:06 2006