> -----Original Message-----
> From: Stefan Küng [mailto:tortoise...@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" <tortoise...@gmail.com
> > <mailto:tortoise...@gmail.com>> wrote:
> >  >
> >  > On 29.05.2011 04:31, Greg Stein wrote:
> >  >> On May 28, 2011 1:39 PM, "Stefan Küng" <tortoise...@gmail.com
> > <mailto:tortoise...@gmail.com>
> >  >> <mailto:tortoise...@gmail.com <mailto:tortoise...@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

Reply via email to