> -----Original Message-----
> From: Stefan Küng [mailto:tortoisesvn_at_gmail.com]
> Sent: zondag 29 mei 2011 10:03
> To: Greg Stein
> Cc: Subversion Development; Daniel Shahaf
> Subject: Re: Windows build, nonexistent functions
>
> On 29.05.2011 09:54, Greg Stein wrote:
> >
> > On May 29, 2011 2:55 AM, "Stefan Küng" <tortoisesvn_at_gmail.com
> > <mailto:tortoisesvn_at_gmail.com>> wrote:
> > >
> > > On 29.05.2011 04:31, Greg Stein wrote:
> > >> On May 28, 2011 1:39 PM, "Stefan Küng" <tortoisesvn_at_gmail.com
> > <mailto:tortoisesvn_at_gmail.com>
> > >> <mailto:tortoisesvn_at_gmail.com <mailto:tortoisesvn_at_gmail.com>>>
> wrote:
> > >...
> > >> >
> > >> > I did a grep search for those functions, and the only files they
> > >> showed up were the headers, no other files contained those function
> > >> names. So it's not because of preprocessor conditionals.
> > >> >
> > >> > I'll wait until tomorrow. If there are no objections until then,
I'll
> > >> commit a change which removes those.
> > >>
> > >> For the conflict_skel functions, please wrap them in #if 0, rather
then
> > >> deleting them. We are going to use them for 1.8.
> > >>
> > >> The other two... as you wish.
> > >
> > >
> > > An #if 0 won't help with extractor.py at all. It will still extract
> > the functions.
> >
> > Eep. Good point.
> >
> > >
> > > If the functions are needed in 1.8, can't we just add them once
> > they're really needed?
> >
> > Sure. My concern was just getting them back when needed. I guess we can
> > just rely on 'svn log' and track down the right revision.
>
> I've adjusted the TSVN build to remove those functions from the
> extractor.py output. So it's not a big deal for me.
> But I'm still wondering whether the Windows build for the svn client
> works. Can anyone here try it?
> If it works, those functions could stay there so you don't have to track
> them down again once you need them.
We only call extractor.py on the header files referenced in 'msvc-export ='
lines of build.conf.
All the functions referenced in this mail thread are library private on a
normal Windows build.
The Windows-RA buildbot uses a shared library build, so its build would have
been broken for more than a year, if this would have been a problem.
Are you seeing this problem in a custom build? ;)
Beer
Received on 2011-05-29 14:25:44 CEST