You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by rh...@apache.org on 2012/06/13 18:10:25 UTC
svn commit: r1349944 - /subversion/trunk/gen-make.py
Author: rhuijben
Date: Wed Jun 13 16:10:25 2012
New Revision: 1349944
URL: http://svn.apache.org/viewvc?rev=1349944&view=rev
Log:
* gen-make.py
Make the --with-neon= and --without-neon arguments on gen-make.py optional,
just like how ./configure handles those. Windows doesn't use ./configure and
this breaks tools that are friendly enough to provide hints.
Modified:
subversion/trunk/gen-make.py
Modified: subversion/trunk/gen-make.py
URL: http://svn.apache.org/viewvc/subversion/trunk/gen-make.py?rev=1349944&r1=1349943&r2=1349944&view=diff
==============================================================================
--- subversion/trunk/gen-make.py (original)
+++ subversion/trunk/gen-make.py Wed Jun 13 16:10:25 2012
@@ -257,6 +257,13 @@ if __name__ == '__main__':
'disable-shared',
'installed-libs=',
'vsnet-version=',
+
+ # Keep distributions that help by adding a path
+ # working. On unix this would be filtered by
+ # configure, but on Windows gen-make.py is used
+ # directly.
+ 'with-neon=',
+ 'without-neon',
])
if len(args) > 1:
_usage_exit("Too many arguments")
@@ -281,6 +288,9 @@ if __name__ == '__main__':
if opt != '--debug':
rest.add(opt, val)
del prev_conf
+ elif opt == '--with-neon' or opt == '--without-neon':
+ # Provide a warning that we ignored these arguments
+ print("Ignoring no longer supported argument '%s'" % opt)
else:
rest.add(opt, val)
Re: svn commit: r1349944 - /subversion/trunk/gen-make.py
Posted by Hyrum K Wright <hy...@wandisco.com>.
On Thu, Jun 14, 2012 at 11:36 AM, Bert Huijben <be...@qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Greg Stein [mailto:gstein@gmail.com]
>> Sent: Thursday, June 14, 2012 10:44 AM
>> To: Bert Huijben; Hyrum K Wright
>> Cc: dev@subversion.apache.org
>> Subject: Re: svn commit: r1349944 - /subversion/trunk/gen-make.py
>>
>> I agree: we should not make changes to Subversion simply to support
>> some buildbots. That is the wrong direction.
>>
>> The buildbots must compensate for changes in *our* codebase. If we add
>> new dependencies, then they must adjust. If we remove dependencies,
>> then they must adjust.
>
> Ok, maybe the response might have been:
>
> We should wait a few days before breaking every Windows Subversion
> development environment to allow them to be fixed first.
>
> I spent most of the night to get things fixed. (Last commit after 3 AM, and
> the final fixes on the buildbot after I woke up)
>
> But I don't understand why somebody just commits a change that he knows
> break things for at least two other developers on the same table. (I had to
> fix Markus development environment too, as he couldn't test the work he was
> working on)
>
> Most unix developers just assume that looking in a system library to find
> things like apr, serf, neon etc. works on all systems.
>
> Windows is by default not a development environment, so there is no standard
> place to look for these things and to work stable we pass explicit
> arguments. Just removing the arguments without notice is breaking things
> directly without a way to recover using the normal routing..
>
> Just like breaking you development svn for commits or reverts breaks your
> entire workflow.
>
>
> I explicitly told Hyrum to wait with this specific change, as this impacts
> more people than all the other removal he did. And instead of providing some
> time or discussing this change on list he just broke things for me and
> others depending on these flags.
I'm sorry about that. I heard "you forgot this part of nuking neon"
so I attempted to rectify that change. I realized it would cause
breakage (as prior neon changes did for *nix environments), but did
not expect them to be large.
> I don't care that this flag will be gone with 1.8, we can catch up well
> before that. And I think for most my cases I did, but maybe others need some
> time too.
>
> This is not just about the buildbots, this is about workflows that are just
> broken beyond repair without notice.
>
>
> I would have liked to have some time to fix things before everything that
> depends on it breaks down. I noted the problem as I assumed that he didn't
> know about things relying on them and he explicitly used that information to
> apply this as a change that 'he forgot about'.
>
> This is just working against other developers. And this entire thread delays
> things more.
>
> Feel free to revert my patch that reintroduced the --XXX-neon flags in a
> week or so.
Thank you for the complete response.
I wasn't trying to be vindictive or penalizing Windows, just cleaning
up what I perceived to be my own mess. As a non-development platform,
Windows probably doesn't get enough love, and those of us who don't
use it regularly probably do not appreciate the difficulty in doing
so.
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
RE: svn commit: r1349944 - /subversion/trunk/gen-make.py
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Greg Stein [mailto:gstein@gmail.com]
> Sent: Thursday, June 14, 2012 10:44 AM
> To: Bert Huijben; Hyrum K Wright
> Cc: dev@subversion.apache.org
> Subject: Re: svn commit: r1349944 - /subversion/trunk/gen-make.py
>
> I agree: we should not make changes to Subversion simply to support
> some buildbots. That is the wrong direction.
>
> The buildbots must compensate for changes in *our* codebase. If we add
> new dependencies, then they must adjust. If we remove dependencies,
> then they must adjust.
Ok, maybe the response might have been:
We should wait a few days before breaking every Windows Subversion
development environment to allow them to be fixed first.
I spent most of the night to get things fixed. (Last commit after 3 AM, and
the final fixes on the buildbot after I woke up)
But I don't understand why somebody just commits a change that he knows
break things for at least two other developers on the same table. (I had to
fix Markus development environment too, as he couldn't test the work he was
working on)
Most unix developers just assume that looking in a system library to find
things like apr, serf, neon etc. works on all systems.
Windows is by default not a development environment, so there is no standard
place to look for these things and to work stable we pass explicit
arguments. Just removing the arguments without notice is breaking things
directly without a way to recover using the normal routing..
Just like breaking you development svn for commits or reverts breaks your
entire workflow.
I explicitly told Hyrum to wait with this specific change, as this impacts
more people than all the other removal he did. And instead of providing some
time or discussing this change on list he just broke things for me and
others depending on these flags.
I don't care that this flag will be gone with 1.8, we can catch up well
before that. And I think for most my cases I did, but maybe others need some
time too.
This is not just about the buildbots, this is about workflows that are just
broken beyond repair without notice.
I would have liked to have some time to fix things before everything that
depends on it breaks down. I noted the problem as I assumed that he didn't
know about things relying on them and he explicitly used that information to
apply this as a change that 'he forgot about'.
This is just working against other developers. And this entire thread delays
things more.
Feel free to revert my patch that reintroduced the --XXX-neon flags in a
week or so.
Bert
Re: svn commit: r1349944 - /subversion/trunk/gen-make.py
Posted by Greg Stein <gs...@gmail.com>.
I agree: we should not make changes to Subversion simply to support
some buildbots. That is the wrong direction.
The buildbots must compensate for changes in *our* codebase. If we add
new dependencies, then they must adjust. If we remove dependencies,
then they must adjust.
On Thu, Jun 14, 2012 at 3:26 AM, Hyrum K Wright
<hy...@wandisco.com> wrote:
> On Thu, Jun 14, 2012 at 1:23 AM, Bert Huijben <be...@qqmail.nl> wrote:
>>> -----Original Message-----
>>> From: Hyrum K Wright [mailto:hyrum.wright@wandisco.com]
>>> Sent: Thursday, June 14, 2012 12:33 AM
>>> To: Bert Huijben
>>> Cc: Michael Pilato; Subversion Development
>>> Subject: Re: svn commit: r1349944 - /subversion/trunk/gen-make.py
>>>
>>> On Wed, Jun 13, 2012 at 9:45 PM, Bert Huijben <be...@qqmail.nl> wrote:
>>> >
>>> >
>>> >> -----Original Message-----
>>> >> From: C. Michael Pilato [mailto:cmpilato@collab.net]
>>> >> Sent: Wednesday, June 13, 2012 9:34 PM
>>> >> To: dev@subversion.apache.org
>>> >> Cc: Hyrum K Wright; commits@subversion.apache.org
>>> >> Subject: Re: svn commit: r1349944 - /subversion/trunk/gen-make.py
>>> >>
>>> >> On 06/13/2012 07:36 PM, Hyrum K Wright wrote:
>>> >> > On Wed, Jun 13, 2012 at 6:10 PM, <rh...@apache.org> wrote:
>>> >> >> Author: rhuijben
>>> >> >> Date: Wed Jun 13 16:10:25 2012
>>> >> >> New Revision: 1349944
>>> >> >>
>>> >> >> URL: http://svn.apache.org/viewvc?rev=1349944&view=rev
>>> >> >> Log:
>>> >> >> * gen-make.py
>>> >> >> Make the --with-neon= and --without-neon arguments on gen-
>>> make.py
>>> >> optional,
>>> >> >> just like how ./configure handles those. Windows doesn't use
>>> ./configure
>>> >> and
>>> >> >> this breaks tools that are friendly enough to provide hints.
>>> >> >
>>> >> > I don't like this change. ./configure *doesn't* work this way: it
>>> >> > errors when attempting to provide the now-defunct neon options.
>>> >>
>>> >> Perhaps Bert meant only that, in general, configure allows you to specify
>>> >> options that it doesn't itself understand (while printing a warning about
>>> >> this fact).
>>> >
>>> > I think most distributions at least share some build code between versions.
>>> >
>>> > The buildbots only have a single set of dependencies for all the branches
>>> we are building. Only once we released 1.9.0 neon will be gone and before
>>> that we still have to support it (and even after that we still have to support all
>>> the Subversion 1.0-1.7 clients that still use neon)
>>>
>>> So, what you're saying is that we have single slaves, with single sets
>>> of scripts building multiple branches. And because of this, we can't
>>> change the dependencies or script arguments on trunk, for fear of
>>> breaking other branches. That sounds a bit like the tail wagging the
>>> dog.
>>>
>>> What would happen if we added a flag on trunk that one of the slaves
>>> needed to build, but didn't exist (and hence error'd) on other
>>> branches? Would we need to backport that flag as a no-op, simply to
>>> make the build slaves happen? That's exactly what this commit does,
>>> only in the forward direction.
>>>
>>> > Things get very easy if you just break the few remaining buildbots without
>>> caring about the consequences, but it doesn’t make Subversion a better
>>> product.
>>>
>>> Making decisions simply to please the bots doesn't make Subversion a
>>> better product, either. They exist to help facilitate development.
>>> If there is a problem with the bots, then FIX THE BOTS, rather than
>>> introducing hacks in an attempt to please them.
>>>
>>> In this specific case that might mean a slightly more complex setup,
>>> which build each branch with a separate set of dependencies / scripts
>>> / inputs, since that's what end users will be doing anyway.
>>
>> Well, maybe you could help writing these scripts instead of breaking them because they have to broken anyway in the future.
>
> I choose not to maintain the bots you choose to host. The slave I
> host is currently offline, if/when it comes back on, I will address
> these issues which impact them. I have helped fix the centos
> buildslave, which I have knowledge of and access to.
>
>> Breaking them 2 minutes after telling you that breaking them will cause huge problems that take much time to solve isn't helping things.
>
> You pointed out a deficiency in my prior patches, which I attempted to fix.
>
>> Why do you prefer 2 of the 3 buildbots to be broken for at least the rest of the hackathon?
>
> I don't. Please don't put words in my mouth.
>
>> Fixing the scripts for the bots, for SharpSvn, for the Slik distribution, for CollabNet's build and several test scenarios takes time.... certainly more time than the 5 minutes you provided.
>
> Those aren't my responsibility. While I think we should be respectful
> of downstream users, people who choose to build directly against trunk
> on a regular basis have to know they are working against a moving
> target, and such breakage is possible, and even quasi-expected.
>
>> And probably more than a few weeks if I'm not delaying other work, which I would have to do if as all my build environments are broken by this change.
>
> Note that I have not asked that you revert this change. I just said
> that I don't like it, because we should think strongly about the
> precedent this sets. The flags to gen-make.py and other build scripts
> are *not* part of our backward compat guarantees, and we shouldn't
> feel required to support them indefinitely. (I noticed your response
> doesn't address the questions I asked along these lines.)
>
> -Hyrum
>
>
> --
>
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com/
Re: svn commit: r1349944 - /subversion/trunk/gen-make.py
Posted by Hyrum K Wright <hy...@wandisco.com>.
On Thu, Jun 14, 2012 at 1:23 AM, Bert Huijben <be...@qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Hyrum K Wright [mailto:hyrum.wright@wandisco.com]
>> Sent: Thursday, June 14, 2012 12:33 AM
>> To: Bert Huijben
>> Cc: Michael Pilato; Subversion Development
>> Subject: Re: svn commit: r1349944 - /subversion/trunk/gen-make.py
>>
>> On Wed, Jun 13, 2012 at 9:45 PM, Bert Huijben <be...@qqmail.nl> wrote:
>> >
>> >
>> >> -----Original Message-----
>> >> From: C. Michael Pilato [mailto:cmpilato@collab.net]
>> >> Sent: Wednesday, June 13, 2012 9:34 PM
>> >> To: dev@subversion.apache.org
>> >> Cc: Hyrum K Wright; commits@subversion.apache.org
>> >> Subject: Re: svn commit: r1349944 - /subversion/trunk/gen-make.py
>> >>
>> >> On 06/13/2012 07:36 PM, Hyrum K Wright wrote:
>> >> > On Wed, Jun 13, 2012 at 6:10 PM, <rh...@apache.org> wrote:
>> >> >> Author: rhuijben
>> >> >> Date: Wed Jun 13 16:10:25 2012
>> >> >> New Revision: 1349944
>> >> >>
>> >> >> URL: http://svn.apache.org/viewvc?rev=1349944&view=rev
>> >> >> Log:
>> >> >> * gen-make.py
>> >> >> Make the --with-neon= and --without-neon arguments on gen-
>> make.py
>> >> optional,
>> >> >> just like how ./configure handles those. Windows doesn't use
>> ./configure
>> >> and
>> >> >> this breaks tools that are friendly enough to provide hints.
>> >> >
>> >> > I don't like this change. ./configure *doesn't* work this way: it
>> >> > errors when attempting to provide the now-defunct neon options.
>> >>
>> >> Perhaps Bert meant only that, in general, configure allows you to specify
>> >> options that it doesn't itself understand (while printing a warning about
>> >> this fact).
>> >
>> > I think most distributions at least share some build code between versions.
>> >
>> > The buildbots only have a single set of dependencies for all the branches
>> we are building. Only once we released 1.9.0 neon will be gone and before
>> that we still have to support it (and even after that we still have to support all
>> the Subversion 1.0-1.7 clients that still use neon)
>>
>> So, what you're saying is that we have single slaves, with single sets
>> of scripts building multiple branches. And because of this, we can't
>> change the dependencies or script arguments on trunk, for fear of
>> breaking other branches. That sounds a bit like the tail wagging the
>> dog.
>>
>> What would happen if we added a flag on trunk that one of the slaves
>> needed to build, but didn't exist (and hence error'd) on other
>> branches? Would we need to backport that flag as a no-op, simply to
>> make the build slaves happen? That's exactly what this commit does,
>> only in the forward direction.
>>
>> > Things get very easy if you just break the few remaining buildbots without
>> caring about the consequences, but it doesn’t make Subversion a better
>> product.
>>
>> Making decisions simply to please the bots doesn't make Subversion a
>> better product, either. They exist to help facilitate development.
>> If there is a problem with the bots, then FIX THE BOTS, rather than
>> introducing hacks in an attempt to please them.
>>
>> In this specific case that might mean a slightly more complex setup,
>> which build each branch with a separate set of dependencies / scripts
>> / inputs, since that's what end users will be doing anyway.
>
> Well, maybe you could help writing these scripts instead of breaking them because they have to broken anyway in the future.
I choose not to maintain the bots you choose to host. The slave I
host is currently offline, if/when it comes back on, I will address
these issues which impact them. I have helped fix the centos
buildslave, which I have knowledge of and access to.
> Breaking them 2 minutes after telling you that breaking them will cause huge problems that take much time to solve isn't helping things.
You pointed out a deficiency in my prior patches, which I attempted to fix.
> Why do you prefer 2 of the 3 buildbots to be broken for at least the rest of the hackathon?
I don't. Please don't put words in my mouth.
> Fixing the scripts for the bots, for SharpSvn, for the Slik distribution, for CollabNet's build and several test scenarios takes time.... certainly more time than the 5 minutes you provided.
Those aren't my responsibility. While I think we should be respectful
of downstream users, people who choose to build directly against trunk
on a regular basis have to know they are working against a moving
target, and such breakage is possible, and even quasi-expected.
> And probably more than a few weeks if I'm not delaying other work, which I would have to do if as all my build environments are broken by this change.
Note that I have not asked that you revert this change. I just said
that I don't like it, because we should think strongly about the
precedent this sets. The flags to gen-make.py and other build scripts
are *not* part of our backward compat guarantees, and we shouldn't
feel required to support them indefinitely. (I noticed your response
doesn't address the questions I asked along these lines.)
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
RE: svn commit: r1349944 - /subversion/trunk/gen-make.py
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Hyrum K Wright [mailto:hyrum.wright@wandisco.com]
> Sent: Thursday, June 14, 2012 12:33 AM
> To: Bert Huijben
> Cc: Michael Pilato; Subversion Development
> Subject: Re: svn commit: r1349944 - /subversion/trunk/gen-make.py
>
> On Wed, Jun 13, 2012 at 9:45 PM, Bert Huijben <be...@qqmail.nl> wrote:
> >
> >
> >> -----Original Message-----
> >> From: C. Michael Pilato [mailto:cmpilato@collab.net]
> >> Sent: Wednesday, June 13, 2012 9:34 PM
> >> To: dev@subversion.apache.org
> >> Cc: Hyrum K Wright; commits@subversion.apache.org
> >> Subject: Re: svn commit: r1349944 - /subversion/trunk/gen-make.py
> >>
> >> On 06/13/2012 07:36 PM, Hyrum K Wright wrote:
> >> > On Wed, Jun 13, 2012 at 6:10 PM, <rh...@apache.org> wrote:
> >> >> Author: rhuijben
> >> >> Date: Wed Jun 13 16:10:25 2012
> >> >> New Revision: 1349944
> >> >>
> >> >> URL: http://svn.apache.org/viewvc?rev=1349944&view=rev
> >> >> Log:
> >> >> * gen-make.py
> >> >> Make the --with-neon= and --without-neon arguments on gen-
> make.py
> >> optional,
> >> >> just like how ./configure handles those. Windows doesn't use
> ./configure
> >> and
> >> >> this breaks tools that are friendly enough to provide hints.
> >> >
> >> > I don't like this change. ./configure *doesn't* work this way: it
> >> > errors when attempting to provide the now-defunct neon options.
> >>
> >> Perhaps Bert meant only that, in general, configure allows you to specify
> >> options that it doesn't itself understand (while printing a warning about
> >> this fact).
> >
> > I think most distributions at least share some build code between versions.
> >
> > The buildbots only have a single set of dependencies for all the branches
> we are building. Only once we released 1.9.0 neon will be gone and before
> that we still have to support it (and even after that we still have to support all
> the Subversion 1.0-1.7 clients that still use neon)
>
> So, what you're saying is that we have single slaves, with single sets
> of scripts building multiple branches. And because of this, we can't
> change the dependencies or script arguments on trunk, for fear of
> breaking other branches. That sounds a bit like the tail wagging the
> dog.
>
> What would happen if we added a flag on trunk that one of the slaves
> needed to build, but didn't exist (and hence error'd) on other
> branches? Would we need to backport that flag as a no-op, simply to
> make the build slaves happen? That's exactly what this commit does,
> only in the forward direction.
>
> > Things get very easy if you just break the few remaining buildbots without
> caring about the consequences, but it doesn’t make Subversion a better
> product.
>
> Making decisions simply to please the bots doesn't make Subversion a
> better product, either. They exist to help facilitate development.
> If there is a problem with the bots, then FIX THE BOTS, rather than
> introducing hacks in an attempt to please them.
>
> In this specific case that might mean a slightly more complex setup,
> which build each branch with a separate set of dependencies / scripts
> / inputs, since that's what end users will be doing anyway.
Well, maybe you could help writing these scripts instead of breaking them because they have to broken anyway in the future.
Breaking them 2 minutes after telling you that breaking them will cause huge problems that take much time to solve isn't helping things.
Why do you prefer 2 of the 3 buildbots to be broken for at least the rest of the hackathon?
Fixing the scripts for the bots, for SharpSvn, for the Slik distribution, for CollabNet's build and several test scenarios takes time.... certainly more time than the 5 minutes you provided.
And probably more than a few weeks if I'm not delaying other work, which I would have to do if as all my build environments are broken by this change.
Bert
Re: svn commit: r1349944 - /subversion/trunk/gen-make.py
Posted by Hyrum K Wright <hy...@wandisco.com>.
On Wed, Jun 13, 2012 at 9:45 PM, Bert Huijben <be...@qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: C. Michael Pilato [mailto:cmpilato@collab.net]
>> Sent: Wednesday, June 13, 2012 9:34 PM
>> To: dev@subversion.apache.org
>> Cc: Hyrum K Wright; commits@subversion.apache.org
>> Subject: Re: svn commit: r1349944 - /subversion/trunk/gen-make.py
>>
>> On 06/13/2012 07:36 PM, Hyrum K Wright wrote:
>> > On Wed, Jun 13, 2012 at 6:10 PM, <rh...@apache.org> wrote:
>> >> Author: rhuijben
>> >> Date: Wed Jun 13 16:10:25 2012
>> >> New Revision: 1349944
>> >>
>> >> URL: http://svn.apache.org/viewvc?rev=1349944&view=rev
>> >> Log:
>> >> * gen-make.py
>> >> Make the --with-neon= and --without-neon arguments on gen-make.py
>> optional,
>> >> just like how ./configure handles those. Windows doesn't use ./configure
>> and
>> >> this breaks tools that are friendly enough to provide hints.
>> >
>> > I don't like this change. ./configure *doesn't* work this way: it
>> > errors when attempting to provide the now-defunct neon options.
>>
>> Perhaps Bert meant only that, in general, configure allows you to specify
>> options that it doesn't itself understand (while printing a warning about
>> this fact).
>
> I think most distributions at least share some build code between versions.
>
> The buildbots only have a single set of dependencies for all the branches we are building. Only once we released 1.9.0 neon will be gone and before that we still have to support it (and even after that we still have to support all the Subversion 1.0-1.7 clients that still use neon)
So, what you're saying is that we have single slaves, with single sets
of scripts building multiple branches. And because of this, we can't
change the dependencies or script arguments on trunk, for fear of
breaking other branches. That sounds a bit like the tail wagging the
dog.
What would happen if we added a flag on trunk that one of the slaves
needed to build, but didn't exist (and hence error'd) on other
branches? Would we need to backport that flag as a no-op, simply to
make the build slaves happen? That's exactly what this commit does,
only in the forward direction.
> Things get very easy if you just break the few remaining buildbots without caring about the consequences, but it doesn’t make Subversion a better product.
Making decisions simply to please the bots doesn't make Subversion a
better product, either. They exist to help facilitate development.
If there is a problem with the bots, then FIX THE BOTS, rather than
introducing hacks in an attempt to please them.
In this specific case that might mean a slightly more complex setup,
which build each branch with a separate set of dependencies / scripts
/ inputs, since that's what end users will be doing anyway.
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
RE: svn commit: r1349944 - /subversion/trunk/gen-make.py
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato@collab.net]
> Sent: Wednesday, June 13, 2012 9:34 PM
> To: dev@subversion.apache.org
> Cc: Hyrum K Wright; commits@subversion.apache.org
> Subject: Re: svn commit: r1349944 - /subversion/trunk/gen-make.py
>
> On 06/13/2012 07:36 PM, Hyrum K Wright wrote:
> > On Wed, Jun 13, 2012 at 6:10 PM, <rh...@apache.org> wrote:
> >> Author: rhuijben
> >> Date: Wed Jun 13 16:10:25 2012
> >> New Revision: 1349944
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1349944&view=rev
> >> Log:
> >> * gen-make.py
> >> Make the --with-neon= and --without-neon arguments on gen-make.py
> optional,
> >> just like how ./configure handles those. Windows doesn't use ./configure
> and
> >> this breaks tools that are friendly enough to provide hints.
> >
> > I don't like this change. ./configure *doesn't* work this way: it
> > errors when attempting to provide the now-defunct neon options.
>
> Perhaps Bert meant only that, in general, configure allows you to specify
> options that it doesn't itself understand (while printing a warning about
> this fact).
I think most distributions at least share some build code between versions.
The buildbots only have a single set of dependencies for all the branches we are building. Only once we released 1.9.0 neon will be gone and before that we still have to support it (and even after that we still have to support all the Subversion 1.0-1.7 clients that still use neon)
Things get very easy if you just break the few remaining buildbots without caring about the consequences, but it doesn’t make Subversion a better product.
Bert
Re: svn commit: r1349944 - /subversion/trunk/gen-make.py
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
C. Michael Pilato wrote on Wed, Jun 13, 2012 at 21:33:53 +0200:
> On 06/13/2012 07:36 PM, Hyrum K Wright wrote:
> > On Wed, Jun 13, 2012 at 6:10 PM, <rh...@apache.org> wrote:
> >> Author: rhuijben
> >> Date: Wed Jun 13 16:10:25 2012
> >> New Revision: 1349944
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1349944&view=rev
> >> Log:
> >> * gen-make.py
> >> Make the --with-neon= and --without-neon arguments on gen-make.py optional,
> >> just like how ./configure handles those. Windows doesn't use ./configure and
> >> this breaks tools that are friendly enough to provide hints.
> >
> > I don't like this change. ./configure *doesn't* work this way: it
> > errors when attempting to provide the now-defunct neon options.
>
> Perhaps Bert meant only that, in general, configure allows you to specify
> options that it doesn't itself understand (while printing a warning about
> this fact).
That's only because we pass such options to APR... and I presume APR's
configure would error on option that _it_ doesn't recognize?
RE: svn commit: r1349944 - /subversion/trunk/gen-make.py
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato@collab.net]
> Sent: Wednesday, June 13, 2012 9:34 PM
> To: dev@subversion.apache.org
> Cc: Hyrum K Wright; commits@subversion.apache.org
> Subject: Re: svn commit: r1349944 - /subversion/trunk/gen-make.py
>
> On 06/13/2012 07:36 PM, Hyrum K Wright wrote:
> > On Wed, Jun 13, 2012 at 6:10 PM, <rh...@apache.org> wrote:
> >> Author: rhuijben
> >> Date: Wed Jun 13 16:10:25 2012
> >> New Revision: 1349944
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1349944&view=rev
> >> Log:
> >> * gen-make.py
> >> Make the --with-neon= and --without-neon arguments on gen-make.py
> optional,
> >> just like how ./configure handles those. Windows doesn't use ./configure
> and
> >> this breaks tools that are friendly enough to provide hints.
> >
> > I don't like this change. ./configure *doesn't* work this way: it
> > errors when attempting to provide the now-defunct neon options.
>
> Perhaps Bert meant only that, in general, configure allows you to specify
> options that it doesn't itself understand (while printing a warning about
> this fact).
I think most distributions at least share some build code between versions.
The buildbots only have a single set of dependencies for all the branches we are building. Only once we released 1.9.0 neon will be gone and before that we still have to support it (and even after that we still have to support all the Subversion 1.0-1.7 clients that still use neon)
Things get very easy if you just break the few remaining buildbots without caring about the consequences, but it doesn’t make Subversion a better product.
Bert
Re: svn commit: r1349944 - /subversion/trunk/gen-make.py
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
C. Michael Pilato wrote on Wed, Jun 13, 2012 at 21:33:53 +0200:
> On 06/13/2012 07:36 PM, Hyrum K Wright wrote:
> > On Wed, Jun 13, 2012 at 6:10 PM, <rh...@apache.org> wrote:
> >> Author: rhuijben
> >> Date: Wed Jun 13 16:10:25 2012
> >> New Revision: 1349944
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1349944&view=rev
> >> Log:
> >> * gen-make.py
> >> Make the --with-neon= and --without-neon arguments on gen-make.py optional,
> >> just like how ./configure handles those. Windows doesn't use ./configure and
> >> this breaks tools that are friendly enough to provide hints.
> >
> > I don't like this change. ./configure *doesn't* work this way: it
> > errors when attempting to provide the now-defunct neon options.
>
> Perhaps Bert meant only that, in general, configure allows you to specify
> options that it doesn't itself understand (while printing a warning about
> this fact).
That's only because we pass such options to APR... and I presume APR's
configure would error on option that _it_ doesn't recognize?
Re: svn commit: r1349944 - /subversion/trunk/gen-make.py
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 06/13/2012 07:36 PM, Hyrum K Wright wrote:
> On Wed, Jun 13, 2012 at 6:10 PM, <rh...@apache.org> wrote:
>> Author: rhuijben
>> Date: Wed Jun 13 16:10:25 2012
>> New Revision: 1349944
>>
>> URL: http://svn.apache.org/viewvc?rev=1349944&view=rev
>> Log:
>> * gen-make.py
>> Make the --with-neon= and --without-neon arguments on gen-make.py optional,
>> just like how ./configure handles those. Windows doesn't use ./configure and
>> this breaks tools that are friendly enough to provide hints.
>
> I don't like this change. ./configure *doesn't* work this way: it
> errors when attempting to provide the now-defunct neon options.
Perhaps Bert meant only that, in general, configure allows you to specify
options that it doesn't itself understand (while printing a warning about
this fact).
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: svn commit: r1349944 - /subversion/trunk/gen-make.py
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 06/13/2012 07:36 PM, Hyrum K Wright wrote:
> On Wed, Jun 13, 2012 at 6:10 PM, <rh...@apache.org> wrote:
>> Author: rhuijben
>> Date: Wed Jun 13 16:10:25 2012
>> New Revision: 1349944
>>
>> URL: http://svn.apache.org/viewvc?rev=1349944&view=rev
>> Log:
>> * gen-make.py
>> Make the --with-neon= and --without-neon arguments on gen-make.py optional,
>> just like how ./configure handles those. Windows doesn't use ./configure and
>> this breaks tools that are friendly enough to provide hints.
>
> I don't like this change. ./configure *doesn't* work this way: it
> errors when attempting to provide the now-defunct neon options.
Perhaps Bert meant only that, in general, configure allows you to specify
options that it doesn't itself understand (while printing a warning about
this fact).
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: svn commit: r1349944 - /subversion/trunk/gen-make.py
Posted by Hyrum K Wright <hy...@wandisco.com>.
On Wed, Jun 13, 2012 at 6:10 PM, <rh...@apache.org> wrote:
> Author: rhuijben
> Date: Wed Jun 13 16:10:25 2012
> New Revision: 1349944
>
> URL: http://svn.apache.org/viewvc?rev=1349944&view=rev
> Log:
> * gen-make.py
> Make the --with-neon= and --without-neon arguments on gen-make.py optional,
> just like how ./configure handles those. Windows doesn't use ./configure and
> this breaks tools that are friendly enough to provide hints.
I don't like this change. ./configure *doesn't* work this way: it
errors when attempting to provide the now-defunct neon options.
Neon is gone, dead, buried. We shouldn't be special casing it in this
manner: people who rely on neon will have more work to do than just
updating their scripts, and we don't need to coddle them along the
way.
-Hyrum
>
> Modified:
> subversion/trunk/gen-make.py
>
> Modified: subversion/trunk/gen-make.py
> URL: http://svn.apache.org/viewvc/subversion/trunk/gen-make.py?rev=1349944&r1=1349943&r2=1349944&view=diff
> ==============================================================================
> --- subversion/trunk/gen-make.py (original)
> +++ subversion/trunk/gen-make.py Wed Jun 13 16:10:25 2012
> @@ -257,6 +257,13 @@ if __name__ == '__main__':
> 'disable-shared',
> 'installed-libs=',
> 'vsnet-version=',
> +
> + # Keep distributions that help by adding a path
> + # working. On unix this would be filtered by
> + # configure, but on Windows gen-make.py is used
> + # directly.
> + 'with-neon=',
> + 'without-neon',
> ])
> if len(args) > 1:
> _usage_exit("Too many arguments")
> @@ -281,6 +288,9 @@ if __name__ == '__main__':
> if opt != '--debug':
> rest.add(opt, val)
> del prev_conf
> + elif opt == '--with-neon' or opt == '--without-neon':
> + # Provide a warning that we ignored these arguments
> + print("Ignoring no longer supported argument '%s'" % opt)
> else:
> rest.add(opt, val)
>
>
>
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Re: svn commit: r1349944 - /subversion/trunk/gen-make.py
Posted by Hyrum K Wright <hy...@wandisco.com>.
On Wed, Jun 13, 2012 at 6:10 PM, <rh...@apache.org> wrote:
> Author: rhuijben
> Date: Wed Jun 13 16:10:25 2012
> New Revision: 1349944
>
> URL: http://svn.apache.org/viewvc?rev=1349944&view=rev
> Log:
> * gen-make.py
> Make the --with-neon= and --without-neon arguments on gen-make.py optional,
> just like how ./configure handles those. Windows doesn't use ./configure and
> this breaks tools that are friendly enough to provide hints.
I don't like this change. ./configure *doesn't* work this way: it
errors when attempting to provide the now-defunct neon options.
Neon is gone, dead, buried. We shouldn't be special casing it in this
manner: people who rely on neon will have more work to do than just
updating their scripts, and we don't need to coddle them along the
way.
-Hyrum
>
> Modified:
> subversion/trunk/gen-make.py
>
> Modified: subversion/trunk/gen-make.py
> URL: http://svn.apache.org/viewvc/subversion/trunk/gen-make.py?rev=1349944&r1=1349943&r2=1349944&view=diff
> ==============================================================================
> --- subversion/trunk/gen-make.py (original)
> +++ subversion/trunk/gen-make.py Wed Jun 13 16:10:25 2012
> @@ -257,6 +257,13 @@ if __name__ == '__main__':
> 'disable-shared',
> 'installed-libs=',
> 'vsnet-version=',
> +
> + # Keep distributions that help by adding a path
> + # working. On unix this would be filtered by
> + # configure, but on Windows gen-make.py is used
> + # directly.
> + 'with-neon=',
> + 'without-neon',
> ])
> if len(args) > 1:
> _usage_exit("Too many arguments")
> @@ -281,6 +288,9 @@ if __name__ == '__main__':
> if opt != '--debug':
> rest.add(opt, val)
> del prev_conf
> + elif opt == '--with-neon' or opt == '--without-neon':
> + # Provide a warning that we ignored these arguments
> + print("Ignoring no longer supported argument '%s'" % opt)
> else:
> rest.add(opt, val)
>
>
>
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/