[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r35262 - trunk/build/ac-macros

From: Stefan Sperling <stsp_at_elego.de>
Date: Thu, 15 Jan 2009 18:41:37 +0000

On Thu, Jan 15, 2009 at 11:26:03AM -0700, Jeremy Whitlock wrote:
> > Wasn't this known to cause problems?
> >
> > http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=17212
>
> I wasn't aware of this.
>
> > We need a comment in neon.m4, this change has been made and reverted
> > multiple times already.
>
> Okay. The biggest problem to me is that there appears to be a lack of
> conformity. What do we (Subversion) do? We don't have a requirement
> either way so it's hard to make a decision either way. How do you
> think this should be handled? Which is more right? Requiring package
> maintainers to deliver the .la files or having Subversion work with
> the shared libraries when using --with-neon?

I don't know. You are right that there seems to be dispute over this,
because some people think .la files are the way to go, e.g. redhat, who say
debian had broken packaging. And some consider them the root of all
evil, e.g. debian/ubuntu, who seem to frantically clean .la files from
their system for some reason I don't know. No idea what other systems
prefer, or whether they even do care.

I think we have made a decision to require .la files back then.
Quite possibly because we only listened to one side of the argument
when it came up.

Maybe we just need to change it so that everyone can have their favourite
way (i.e. add a configure option to select what type of linking should
be done)? That would at least keep us out of this stupid dispute.

But as long as we're defaulting to one way, we should at least be consistent
and stick to that. I guess that whenever we change the default, someone
somewhere will need to make an adjustment to get Subversion to compile
again.

Stefan
Received on 2009-01-15 19:41:59 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.