Work is now underway to bring GNU make 3.82 into the tree. Sadly, there are a number of rather unfortunate backwards incompatibility issues between this and 3.81 which makes a simple replacement unworkable.

A new port, devel/gmake381 has just been committed to the tree which is a heavily stripped down 3.81 version (just the binary, installed as ${LOCALBASE}/bin/gmake381, no NLS support. It is also currently marked IGNORE and is NOT attached to devel/Makefile. Please do NOT use it directly in any way, shape or form.

The next steps are as follows:

1. A patchset will be implemented, upgrading devel/gmake to 3.82, attaching devel/gmake381 to the build, and extending the USE_GMAKE variable so that a value of 'yes' will continue to use devel/gmake (now 3.82) and '381' will use the older 3.81

2. -exp runs will be iterated over to determine which ports break building with 3.82, and they will be marked as USE_GMAKE=381 to allow them to continue to build. A list of such ports will be maintained and posted.

3. devel/gmake381 will then be marked DEPRECATED with a suitable EXPIRATION_DATE (at least 6 months), at which point it will be removed, and the USE_GMAKE=381 logic also reverted, so that everything will go back to using devel/gmake. Note: it will not be necessary to edit individual port Makefiles back to USE_GMAKE=yes, since the checks for USE_GMAKE only look to see if the variable is defined. This will provide for ease of use (grep -R USE_GMAKE=381 ports/) to pick up any stragglers -- not to mention the fact that they'll most likely be broken in weird and interesting ways.

A followup posting will occur as and when steps (1) and (2) have been completed.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

Work is now underway to bring GNU make 3.82 into the tree. Sadly, there are a number of rather unfortunate backwards incompatibility issues between this and 3.81 which makes a simple replacement unworkable.

A new port, devel/gmake381 has just been committed to the tree which is a heavily stripped down 3.81 version (just the binary, installed as ${LOCALBASE}/bin/gmake381, no NLS support. It is also currently marked IGNORE and is NOT attached to devel/Makefile. Please do NOT use it directly in any way, shape or form.

The next steps are as follows:

1. A patchset will be implemented, upgrading devel/gmake to 3.82, attaching devel/gmake381 to the build, and extending the USE_GMAKE variable so that a value of 'yes' will continue to use devel/gmake (now 3.82) and '381' will use the older 3.81

2. -exp runs will be iterated over to determine which ports break building with 3.82, and they will be marked as USE_GMAKE=381 to allow them to continue to build. A list of such ports will be maintained and posted.

3. devel/gmake381 will then be marked DEPRECATED with a suitable EXPIRATION_DATE (at least 6 months), at which point it will be removed, and the USE_GMAKE=381 logic also reverted, so that everything will go back to using devel/gmake. Note: it will not be necessary to edit individual port Makefiles back to USE_GMAKE=yes, since the checks for USE_GMAKE only look to see if the variable is defined. This will provide for ease of use (grep -R USE_GMAKE=381 ports/) to pick up any stragglers -- not to mention the fact that they'll most likely be broken in weird and interesting ways.

A followup posting will occur as and when steps (1) and (2) have been completed.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 09:43, Ade Lovett wrote:
> Work is now underway to bring GNU make 3.82 into the tree. Sadly,
> there are a number of rather unfortunate backwards incompatibility
> issues between this and 3.81 which makes a simple replacement
> unworkable.

Can you give us an idea of how many ports we're talking about? Rather
than having 2 gmake ports (which is likely to last for a very long time,
"best laid plans" aside) can we at least explore the idea of fixing
things that are broken to work with 3.82 first? My suggestion is to do
the -exp run, then post here and to maintainers of broken ports directly
and see what a reasonable time frame would be to get things fixed the
right way first.

My understanding is that there is _currently_ no pressure to get gmake
upgraded, so at least exploring the idea of doing it without a kludge
seems reasonable to me, although I'm happy to be proven wrong.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

Work is now underway to bring GNU make 3.82 into the tree. Sadly, there are a number of rather unfortunate backwards incompatibility issues between this and 3.81 which makes a simple replacement unworkable.

A new port, devel/gmake381 has just been committed to the tree which is a heavily stripped down 3.81 version (just the binary, installed as ${LOCALBASE}/bin/gmake381, no NLS support. It is also currently marked IGNORE and is NOT attached to devel/Makefile. Please do NOT use it directly in any way, shape or form.

The next steps are as follows:

1. A patchset will be implemented, upgrading devel/gmake to 3.82, attaching devel/gmake381 to the build, and extending the USE_GMAKE variable so that a value of 'yes' will continue to use devel/gmake (now 3.82) and '381' will use the older 3.81

2. -exp runs will be iterated over to determine which ports break building with 3.82, and they will be marked as USE_GMAKE=381 to allow them to continue to build. A list of such ports will be maintained and posted.

3. devel/gmake381 will then be marked DEPRECATED with a suitable EXPIRATION_DATE (at least 6 months), at which point it will be removed, and the USE_GMAKE=381 logic also reverted, so that everything will go back to using devel/gmake. Note: it will not be necessary to edit individual port Makefiles back to USE_GMAKE=yes, since the checks for USE_GMAKE only look to see if the variable is defined. This will provide for ease of use (grep -R USE_GMAKE=381 ports/) to pick up any stragglers -- not to mention the fact that they'll most likely be broken in weird and interesting ways.

A followup posting will occur as and when steps (1) and (2) have been completed.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 09:43, Ade Lovett wrote:
> Work is now underway to bring GNU make 3.82 into the tree. Sadly,
> there are a number of rather unfortunate backwards incompatibility
> issues between this and 3.81 which makes a simple replacement
> unworkable.

Can you give us an idea of how many ports we're talking about? Rather
than having 2 gmake ports (which is likely to last for a very long time,
"best laid plans" aside) can we at least explore the idea of fixing
things that are broken to work with 3.82 first? My suggestion is to do
the -exp run, then post here and to maintainers of broken ports directly
and see what a reasonable time frame would be to get things fixed the
right way first.

My understanding is that there is _currently_ no pressure to get gmake
upgraded, so at least exploring the idea of doing it without a kludge
seems reasonable to me, although I'm happy to be proven wrong.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 13:24 , Doug Barton wrote:
> Can you give us an idea of how many ports we're talking about? Rather than having 2 gmake ports (which is likely to last for a very long time, "best laid plans" aside) can we at least explore the idea of fixing things that are broken to work with 3.82 first? My suggestion is to do the -exp run, then post here and to maintainers of broken ports directly and see what a reasonable time frame would be to get things fixed the right way first.

Preliminary runs show ~50 ports that break with 3.82, some of them unfortunately being dependencies for a reasonable number of others. An -exp has already been run, though there were a number of false positives for whatever reason.

There will absolutely _not_ be two gmake ports for anything more than a suitable deprecation period (if it is determined to move ahead) or for perhaps a month (specifically note that devel/gmake381 is marked IGNORE and not attached to the tree, so anyone trying to use it will have ... problems) if it's too much in the way of hacking.

> My understanding is that there is _currently_ no pressure to get gmake upgraded, so at least exploring the idea of doing it without a kludge seems reasonable to me, although I'm happy to be proven wrong.

The "kludge", in terms of actually testing things to get empirical data, rather than hand-waving about the sky falling, is ~4 lines of code in bsd.port.mk. We have a plan, we're going to get the results of that plan, and then do some analysis on it. Working closely with the pkgsrc tree that already _is_ at gmake-3.82

You may find a more productive approach would be to wander over to the gnumake mailing list, and ask why such a massive amount of backwards incompatibility was introduced in a minor version upgrade. Of course, that's entirely your prerogative. In the meantime, I along with a few others are actually going to _do_ the work involved in _testing_ the _possibility_ of this instead of sitting in our armchairs.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

Work is now underway to bring GNU make 3.82 into the tree. Sadly, there are a number of rather unfortunate backwards incompatibility issues between this and 3.81 which makes a simple replacement unworkable.

A new port, devel/gmake381 has just been committed to the tree which is a heavily stripped down 3.81 version (just the binary, installed as ${LOCALBASE}/bin/gmake381, no NLS support. It is also currently marked IGNORE and is NOT attached to devel/Makefile. Please do NOT use it directly in any way, shape or form.

The next steps are as follows:

1. A patchset will be implemented, upgrading devel/gmake to 3.82, attaching devel/gmake381 to the build, and extending the USE_GMAKE variable so that a value of 'yes' will continue to use devel/gmake (now 3.82) and '381' will use the older 3.81

2. -exp runs will be iterated over to determine which ports break building with 3.82, and they will be marked as USE_GMAKE=381 to allow them to continue to build. A list of such ports will be maintained and posted.

3. devel/gmake381 will then be marked DEPRECATED with a suitable EXPIRATION_DATE (at least 6 months), at which point it will be removed, and the USE_GMAKE=381 logic also reverted, so that everything will go back to using devel/gmake. Note: it will not be necessary to edit individual port Makefiles back to USE_GMAKE=yes, since the checks for USE_GMAKE only look to see if the variable is defined. This will provide for ease of use (grep -R USE_GMAKE=381 ports/) to pick up any stragglers -- not to mention the fact that they'll most likely be broken in weird and interesting ways.

A followup posting will occur as and when steps (1) and (2) have been completed.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 09:43, Ade Lovett wrote:
> Work is now underway to bring GNU make 3.82 into the tree. Sadly,
> there are a number of rather unfortunate backwards incompatibility
> issues between this and 3.81 which makes a simple replacement
> unworkable.

Can you give us an idea of how many ports we're talking about? Rather
than having 2 gmake ports (which is likely to last for a very long time,
"best laid plans" aside) can we at least explore the idea of fixing
things that are broken to work with 3.82 first? My suggestion is to do
the -exp run, then post here and to maintainers of broken ports directly
and see what a reasonable time frame would be to get things fixed the
right way first.

My understanding is that there is _currently_ no pressure to get gmake
upgraded, so at least exploring the idea of doing it without a kludge
seems reasonable to me, although I'm happy to be proven wrong.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 13:24 , Doug Barton wrote:
> Can you give us an idea of how many ports we're talking about? Rather than having 2 gmake ports (which is likely to last for a very long time, "best laid plans" aside) can we at least explore the idea of fixing things that are broken to work with 3.82 first? My suggestion is to do the -exp run, then post here and to maintainers of broken ports directly and see what a reasonable time frame would be to get things fixed the right way first.

Preliminary runs show ~50 ports that break with 3.82, some of them unfortunately being dependencies for a reasonable number of others. An -exp has already been run, though there were a number of false positives for whatever reason.

There will absolutely _not_ be two gmake ports for anything more than a suitable deprecation period (if it is determined to move ahead) or for perhaps a month (specifically note that devel/gmake381 is marked IGNORE and not attached to the tree, so anyone trying to use it will have ... problems) if it's too much in the way of hacking.

> My understanding is that there is _currently_ no pressure to get gmake upgraded, so at least exploring the idea of doing it without a kludge seems reasonable to me, although I'm happy to be proven wrong.

The "kludge", in terms of actually testing things to get empirical data, rather than hand-waving about the sky falling, is ~4 lines of code in bsd.port.mk. We have a plan, we're going to get the results of that plan, and then do some analysis on it. Working closely with the pkgsrc tree that already _is_ at gmake-3.82

You may find a more productive approach would be to wander over to the gnumake mailing list, and ask why such a massive amount of backwards incompatibility was introduced in a minor version upgrade. Of course, that's entirely your prerogative. In the meantime, I along with a few others are actually going to _do_ the work involved in _testing_ the _possibility_ of this instead of sitting in our armchairs.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 12:05, Ade Lovett wrote:
>
> On Mar 10, 2011, at 13:24 , Doug Barton wrote:
>> Can you give us an idea of how many ports we're talking about?
>> Rather than having 2 gmake ports (which is likely to last for a
>> very long time, "best laid plans" aside) can we at least explore
>> the idea of fixing things that are broken to work with 3.82 first?
>> My suggestion is to do the -exp run, then post here and to
>> maintainers of broken ports directly and see what a reasonable time
>> frame would be to get things fixed the right way first.
>
> Preliminary runs show ~50 ports that break with 3.82, some of them
> unfortunately being dependencies for a reasonable number of others.
> An -exp has already been run, though there were a number of false
> positives for whatever reason.

What I'm suggesting is that the URL for the logs of that run get posted
here, along with contacting the maintainers of the affected ports. Then
let's see what people have to say about getting them fixed sooner rather
than later. Can you explain why doing that would be a bad idea?

> There will absolutely _not_ be two gmake ports for anything more than
> a suitable deprecation period

I admire your optimism, however experience tells us that once these
types of accomodations get into the tree, they stay there for a long time.

>> My understanding is that there is _currently_ no pressure to get
>> gmake upgraded, so at least exploring the idea of doing it without
>> a kludge seems reasonable to me, although I'm happy to be proven
>> wrong.
>
> The "kludge", in terms of actually testing things to get empirical
> data, rather than hand-waving about the sky falling,

Um, no one said the sky is falling, and you've reacted emotionally to
the term "kludge" rather than answering my question about what the
urgency is to get the update done.

> We have a plan, we're going to get the results
> of that plan, and then do some analysis on it.

And my concern is that the plan seems to have been formulated without
wider input from the community. So I ask again ... what harm can come
from at least trying to fix the broken ports first?


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

Work is now underway to bring GNU make 3.82 into the tree. Sadly, there are a number of rather unfortunate backwards incompatibility issues between this and 3.81 which makes a simple replacement unworkable.

A new port, devel/gmake381 has just been committed to the tree which is a heavily stripped down 3.81 version (just the binary, installed as ${LOCALBASE}/bin/gmake381, no NLS support. It is also currently marked IGNORE and is NOT attached to devel/Makefile. Please do NOT use it directly in any way, shape or form.

The next steps are as follows:

1. A patchset will be implemented, upgrading devel/gmake to 3.82, attaching devel/gmake381 to the build, and extending the USE_GMAKE variable so that a value of 'yes' will continue to use devel/gmake (now 3.82) and '381' will use the older 3.81

2. -exp runs will be iterated over to determine which ports break building with 3.82, and they will be marked as USE_GMAKE=381 to allow them to continue to build. A list of such ports will be maintained and posted.

3. devel/gmake381 will then be marked DEPRECATED with a suitable EXPIRATION_DATE (at least 6 months), at which point it will be removed, and the USE_GMAKE=381 logic also reverted, so that everything will go back to using devel/gmake. Note: it will not be necessary to edit individual port Makefiles back to USE_GMAKE=yes, since the checks for USE_GMAKE only look to see if the variable is defined. This will provide for ease of use (grep -R USE_GMAKE=381 ports/) to pick up any stragglers -- not to mention the fact that they'll most likely be broken in weird and interesting ways.

A followup posting will occur as and when steps (1) and (2) have been completed.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 09:43, Ade Lovett wrote:
> Work is now underway to bring GNU make 3.82 into the tree. Sadly,
> there are a number of rather unfortunate backwards incompatibility
> issues between this and 3.81 which makes a simple replacement
> unworkable.

Can you give us an idea of how many ports we're talking about? Rather
than having 2 gmake ports (which is likely to last for a very long time,
"best laid plans" aside) can we at least explore the idea of fixing
things that are broken to work with 3.82 first? My suggestion is to do
the -exp run, then post here and to maintainers of broken ports directly
and see what a reasonable time frame would be to get things fixed the
right way first.

My understanding is that there is _currently_ no pressure to get gmake
upgraded, so at least exploring the idea of doing it without a kludge
seems reasonable to me, although I'm happy to be proven wrong.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 13:24 , Doug Barton wrote:
> Can you give us an idea of how many ports we're talking about? Rather than having 2 gmake ports (which is likely to last for a very long time, "best laid plans" aside) can we at least explore the idea of fixing things that are broken to work with 3.82 first? My suggestion is to do the -exp run, then post here and to maintainers of broken ports directly and see what a reasonable time frame would be to get things fixed the right way first.

Preliminary runs show ~50 ports that break with 3.82, some of them unfortunately being dependencies for a reasonable number of others. An -exp has already been run, though there were a number of false positives for whatever reason.

There will absolutely _not_ be two gmake ports for anything more than a suitable deprecation period (if it is determined to move ahead) or for perhaps a month (specifically note that devel/gmake381 is marked IGNORE and not attached to the tree, so anyone trying to use it will have ... problems) if it's too much in the way of hacking.

> My understanding is that there is _currently_ no pressure to get gmake upgraded, so at least exploring the idea of doing it without a kludge seems reasonable to me, although I'm happy to be proven wrong.

The "kludge", in terms of actually testing things to get empirical data, rather than hand-waving about the sky falling, is ~4 lines of code in bsd.port.mk. We have a plan, we're going to get the results of that plan, and then do some analysis on it. Working closely with the pkgsrc tree that already _is_ at gmake-3.82

You may find a more productive approach would be to wander over to the gnumake mailing list, and ask why such a massive amount of backwards incompatibility was introduced in a minor version upgrade. Of course, that's entirely your prerogative. In the meantime, I along with a few others are actually going to _do_ the work involved in _testing_ the _possibility_ of this instead of sitting in our armchairs.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 12:05, Ade Lovett wrote:
>
> On Mar 10, 2011, at 13:24 , Doug Barton wrote:
>> Can you give us an idea of how many ports we're talking about?
>> Rather than having 2 gmake ports (which is likely to last for a
>> very long time, "best laid plans" aside) can we at least explore
>> the idea of fixing things that are broken to work with 3.82 first?
>> My suggestion is to do the -exp run, then post here and to
>> maintainers of broken ports directly and see what a reasonable time
>> frame would be to get things fixed the right way first.
>
> Preliminary runs show ~50 ports that break with 3.82, some of them
> unfortunately being dependencies for a reasonable number of others.
> An -exp has already been run, though there were a number of false
> positives for whatever reason.

What I'm suggesting is that the URL for the logs of that run get posted
here, along with contacting the maintainers of the affected ports. Then
let's see what people have to say about getting them fixed sooner rather
than later. Can you explain why doing that would be a bad idea?

> There will absolutely _not_ be two gmake ports for anything more than
> a suitable deprecation period

I admire your optimism, however experience tells us that once these
types of accomodations get into the tree, they stay there for a long time.

>> My understanding is that there is _currently_ no pressure to get
>> gmake upgraded, so at least exploring the idea of doing it without
>> a kludge seems reasonable to me, although I'm happy to be proven
>> wrong.
>
> The "kludge", in terms of actually testing things to get empirical
> data, rather than hand-waving about the sky falling,

Um, no one said the sky is falling, and you've reacted emotionally to
the term "kludge" rather than answering my question about what the
urgency is to get the update done.

> We have a plan, we're going to get the results
> of that plan, and then do some analysis on it.

And my concern is that the plan seems to have been formulated without
wider input from the community. So I ask again ... what harm can come
from at least trying to fix the broken ports first?


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 14:21 , Doug Barton wrote:
> What I'm suggesting is that the URL for the logs of that run get posted here, along with contacting the maintainers of the affected ports. Then let's see what people have to say about getting them fixed sooner rather than later. Can you explain why doing that would be a bad idea?

Those 50 or so ports are not the complete picture. Some of them are preventing other ports from being built. So, we cycle through an -exp run adding USE_GMAKE=381 (it's not a library or anything, just an executable, and in the context of clean building, only one or the other will exist for a specific port -exp build, so there's no question of interaction) until we have _all_ of the affected ports.

Then the list gets posted somewhere, USE_GMAKE=381 goes active, then there's a period (6-7 months) for folks to clean things up, at which point USE_GMAKE=381 does exactly the same as USE_GMAKE=yes (use gmake-3.82) -- ports that get fixed after this date simply change USE_GMAKE=381 -> USE_GMAKE=yes (cosmetic change only), and a list of known-broken ports can still be determined by grepping for 'USE_GMAKE=381'. If updates to those ports fix them, change USE_GMAKE back to 'yes'.

> I admire your optimism, however experience tells us that once these types of accomodations get into the tree, they stay there for a long time.

There is no issue of optimism about it. gmake-3.82 _will_ be the sole version of GNU make in the tree by (at latest) the end of this year.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

Work is now underway to bring GNU make 3.82 into the tree. Sadly, there are a number of rather unfortunate backwards incompatibility issues between this and 3.81 which makes a simple replacement unworkable.

A new port, devel/gmake381 has just been committed to the tree which is a heavily stripped down 3.81 version (just the binary, installed as ${LOCALBASE}/bin/gmake381, no NLS support. It is also currently marked IGNORE and is NOT attached to devel/Makefile. Please do NOT use it directly in any way, shape or form.

The next steps are as follows:

1. A patchset will be implemented, upgrading devel/gmake to 3.82, attaching devel/gmake381 to the build, and extending the USE_GMAKE variable so that a value of 'yes' will continue to use devel/gmake (now 3.82) and '381' will use the older 3.81

2. -exp runs will be iterated over to determine which ports break building with 3.82, and they will be marked as USE_GMAKE=381 to allow them to continue to build. A list of such ports will be maintained and posted.

3. devel/gmake381 will then be marked DEPRECATED with a suitable EXPIRATION_DATE (at least 6 months), at which point it will be removed, and the USE_GMAKE=381 logic also reverted, so that everything will go back to using devel/gmake. Note: it will not be necessary to edit individual port Makefiles back to USE_GMAKE=yes, since the checks for USE_GMAKE only look to see if the variable is defined. This will provide for ease of use (grep -R USE_GMAKE=381 ports/) to pick up any stragglers -- not to mention the fact that they'll most likely be broken in weird and interesting ways.

A followup posting will occur as and when steps (1) and (2) have been completed.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 09:43, Ade Lovett wrote:
> Work is now underway to bring GNU make 3.82 into the tree. Sadly,
> there are a number of rather unfortunate backwards incompatibility
> issues between this and 3.81 which makes a simple replacement
> unworkable.

Can you give us an idea of how many ports we're talking about? Rather
than having 2 gmake ports (which is likely to last for a very long time,
"best laid plans" aside) can we at least explore the idea of fixing
things that are broken to work with 3.82 first? My suggestion is to do
the -exp run, then post here and to maintainers of broken ports directly
and see what a reasonable time frame would be to get things fixed the
right way first.

My understanding is that there is _currently_ no pressure to get gmake
upgraded, so at least exploring the idea of doing it without a kludge
seems reasonable to me, although I'm happy to be proven wrong.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 13:24 , Doug Barton wrote:
> Can you give us an idea of how many ports we're talking about? Rather than having 2 gmake ports (which is likely to last for a very long time, "best laid plans" aside) can we at least explore the idea of fixing things that are broken to work with 3.82 first? My suggestion is to do the -exp run, then post here and to maintainers of broken ports directly and see what a reasonable time frame would be to get things fixed the right way first.

Preliminary runs show ~50 ports that break with 3.82, some of them unfortunately being dependencies for a reasonable number of others. An -exp has already been run, though there were a number of false positives for whatever reason.

There will absolutely _not_ be two gmake ports for anything more than a suitable deprecation period (if it is determined to move ahead) or for perhaps a month (specifically note that devel/gmake381 is marked IGNORE and not attached to the tree, so anyone trying to use it will have ... problems) if it's too much in the way of hacking.

> My understanding is that there is _currently_ no pressure to get gmake upgraded, so at least exploring the idea of doing it without a kludge seems reasonable to me, although I'm happy to be proven wrong.

The "kludge", in terms of actually testing things to get empirical data, rather than hand-waving about the sky falling, is ~4 lines of code in bsd.port.mk. We have a plan, we're going to get the results of that plan, and then do some analysis on it. Working closely with the pkgsrc tree that already _is_ at gmake-3.82

You may find a more productive approach would be to wander over to the gnumake mailing list, and ask why such a massive amount of backwards incompatibility was introduced in a minor version upgrade. Of course, that's entirely your prerogative. In the meantime, I along with a few others are actually going to _do_ the work involved in _testing_ the _possibility_ of this instead of sitting in our armchairs.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 12:05, Ade Lovett wrote:
>
> On Mar 10, 2011, at 13:24 , Doug Barton wrote:
>> Can you give us an idea of how many ports we're talking about?
>> Rather than having 2 gmake ports (which is likely to last for a
>> very long time, "best laid plans" aside) can we at least explore
>> the idea of fixing things that are broken to work with 3.82 first?
>> My suggestion is to do the -exp run, then post here and to
>> maintainers of broken ports directly and see what a reasonable time
>> frame would be to get things fixed the right way first.
>
> Preliminary runs show ~50 ports that break with 3.82, some of them
> unfortunately being dependencies for a reasonable number of others.
> An -exp has already been run, though there were a number of false
> positives for whatever reason.

What I'm suggesting is that the URL for the logs of that run get posted
here, along with contacting the maintainers of the affected ports. Then
let's see what people have to say about getting them fixed sooner rather
than later. Can you explain why doing that would be a bad idea?

> There will absolutely _not_ be two gmake ports for anything more than
> a suitable deprecation period

I admire your optimism, however experience tells us that once these
types of accomodations get into the tree, they stay there for a long time.

>> My understanding is that there is _currently_ no pressure to get
>> gmake upgraded, so at least exploring the idea of doing it without
>> a kludge seems reasonable to me, although I'm happy to be proven
>> wrong.
>
> The "kludge", in terms of actually testing things to get empirical
> data, rather than hand-waving about the sky falling,

Um, no one said the sky is falling, and you've reacted emotionally to
the term "kludge" rather than answering my question about what the
urgency is to get the update done.

> We have a plan, we're going to get the results
> of that plan, and then do some analysis on it.

And my concern is that the plan seems to have been formulated without
wider input from the community. So I ask again ... what harm can come
from at least trying to fix the broken ports first?


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 14:21 , Doug Barton wrote:
> What I'm suggesting is that the URL for the logs of that run get posted here, along with contacting the maintainers of the affected ports. Then let's see what people have to say about getting them fixed sooner rather than later. Can you explain why doing that would be a bad idea?

Those 50 or so ports are not the complete picture. Some of them are preventing other ports from being built. So, we cycle through an -exp run adding USE_GMAKE=381 (it's not a library or anything, just an executable, and in the context of clean building, only one or the other will exist for a specific port -exp build, so there's no question of interaction) until we have _all_ of the affected ports.

Then the list gets posted somewhere, USE_GMAKE=381 goes active, then there's a period (6-7 months) for folks to clean things up, at which point USE_GMAKE=381 does exactly the same as USE_GMAKE=yes (use gmake-3.82) -- ports that get fixed after this date simply change USE_GMAKE=381 -> USE_GMAKE=yes (cosmetic change only), and a list of known-broken ports can still be determined by grepping for 'USE_GMAKE=381'. If updates to those ports fix them, change USE_GMAKE back to 'yes'.

> I admire your optimism, however experience tells us that once these types of accomodations get into the tree, they stay there for a long time.

There is no issue of optimism about it. gmake-3.82 _will_ be the sole version of GNU make in the tree by (at latest) the end of this year.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 12:52, Ade Lovett wrote:
>
> On Mar 10, 2011, at 14:21 , Doug Barton wrote:
>> What I'm suggesting is that the URL for the logs of that run get
>> posted here, along with contacting the maintainers of the affected
>> ports. Then let's see what people have to say about getting them
>> fixed sooner rather than later. Can you explain why doing that
>> would be a bad idea?
>
> Those 50 or so ports are not the complete picture. Some of them are
> preventing other ports from being built. So, we cycle through an
> -exp run adding USE_GMAKE=381 (it's not a library or anything, just
> an executable, and in the context of clean building, only one or the
> other will exist for a specific port -exp build, so there's no
> question of interaction) until we have _all_ of the affected ports.
>
> Then the list gets posted somewhere,

Great!

> USE_GMAKE=381 goes active,

That's the bit that we disagree on, but your unwillingness to answer the
question I've posed twice now tells me clearly that you are determined
to follow this course of action, so I give up.

>> I admire your optimism, however experience tells us that once these
>> types of accomodations get into the tree, they stay there for a
>> long time.
>
> There is no issue of optimism about it. gmake-3.82 _will_ be the
> sole version of GNU make in the tree by (at latest) the end of this
> year.

You've already slipped your deadline from 6 months firm, to 6-7 months,
now to 9 months in the course of just a few emails. I'd be willing to
wager $BEVERAGE of your choice that we enter 2012 with multiple gmakes
in the ports tree. But like I said, I'd be glad to be proven wrong. :)


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

Work is now underway to bring GNU make 3.82 into the tree. Sadly, there are a number of rather unfortunate backwards incompatibility issues between this and 3.81 which makes a simple replacement unworkable.

A new port, devel/gmake381 has just been committed to the tree which is a heavily stripped down 3.81 version (just the binary, installed as ${LOCALBASE}/bin/gmake381, no NLS support. It is also currently marked IGNORE and is NOT attached to devel/Makefile. Please do NOT use it directly in any way, shape or form.

The next steps are as follows:

1. A patchset will be implemented, upgrading devel/gmake to 3.82, attaching devel/gmake381 to the build, and extending the USE_GMAKE variable so that a value of 'yes' will continue to use devel/gmake (now 3.82) and '381' will use the older 3.81

2. -exp runs will be iterated over to determine which ports break building with 3.82, and they will be marked as USE_GMAKE=381 to allow them to continue to build. A list of such ports will be maintained and posted.

3. devel/gmake381 will then be marked DEPRECATED with a suitable EXPIRATION_DATE (at least 6 months), at which point it will be removed, and the USE_GMAKE=381 logic also reverted, so that everything will go back to using devel/gmake. Note: it will not be necessary to edit individual port Makefiles back to USE_GMAKE=yes, since the checks for USE_GMAKE only look to see if the variable is defined. This will provide for ease of use (grep -R USE_GMAKE=381 ports/) to pick up any stragglers -- not to mention the fact that they'll most likely be broken in weird and interesting ways.

A followup posting will occur as and when steps (1) and (2) have been completed.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 09:43, Ade Lovett wrote:
> Work is now underway to bring GNU make 3.82 into the tree. Sadly,
> there are a number of rather unfortunate backwards incompatibility
> issues between this and 3.81 which makes a simple replacement
> unworkable.

Can you give us an idea of how many ports we're talking about? Rather
than having 2 gmake ports (which is likely to last for a very long time,
"best laid plans" aside) can we at least explore the idea of fixing
things that are broken to work with 3.82 first? My suggestion is to do
the -exp run, then post here and to maintainers of broken ports directly
and see what a reasonable time frame would be to get things fixed the
right way first.

My understanding is that there is _currently_ no pressure to get gmake
upgraded, so at least exploring the idea of doing it without a kludge
seems reasonable to me, although I'm happy to be proven wrong.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 13:24 , Doug Barton wrote:
> Can you give us an idea of how many ports we're talking about? Rather than having 2 gmake ports (which is likely to last for a very long time, "best laid plans" aside) can we at least explore the idea of fixing things that are broken to work with 3.82 first? My suggestion is to do the -exp run, then post here and to maintainers of broken ports directly and see what a reasonable time frame would be to get things fixed the right way first.

Preliminary runs show ~50 ports that break with 3.82, some of them unfortunately being dependencies for a reasonable number of others. An -exp has already been run, though there were a number of false positives for whatever reason.

There will absolutely _not_ be two gmake ports for anything more than a suitable deprecation period (if it is determined to move ahead) or for perhaps a month (specifically note that devel/gmake381 is marked IGNORE and not attached to the tree, so anyone trying to use it will have ... problems) if it's too much in the way of hacking.

> My understanding is that there is _currently_ no pressure to get gmake upgraded, so at least exploring the idea of doing it without a kludge seems reasonable to me, although I'm happy to be proven wrong.

The "kludge", in terms of actually testing things to get empirical data, rather than hand-waving about the sky falling, is ~4 lines of code in bsd.port.mk. We have a plan, we're going to get the results of that plan, and then do some analysis on it. Working closely with the pkgsrc tree that already _is_ at gmake-3.82

You may find a more productive approach would be to wander over to the gnumake mailing list, and ask why such a massive amount of backwards incompatibility was introduced in a minor version upgrade. Of course, that's entirely your prerogative. In the meantime, I along with a few others are actually going to _do_ the work involved in _testing_ the _possibility_ of this instead of sitting in our armchairs.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 12:05, Ade Lovett wrote:
>
> On Mar 10, 2011, at 13:24 , Doug Barton wrote:
>> Can you give us an idea of how many ports we're talking about?
>> Rather than having 2 gmake ports (which is likely to last for a
>> very long time, "best laid plans" aside) can we at least explore
>> the idea of fixing things that are broken to work with 3.82 first?
>> My suggestion is to do the -exp run, then post here and to
>> maintainers of broken ports directly and see what a reasonable time
>> frame would be to get things fixed the right way first.
>
> Preliminary runs show ~50 ports that break with 3.82, some of them
> unfortunately being dependencies for a reasonable number of others.
> An -exp has already been run, though there were a number of false
> positives for whatever reason.

What I'm suggesting is that the URL for the logs of that run get posted
here, along with contacting the maintainers of the affected ports. Then
let's see what people have to say about getting them fixed sooner rather
than later. Can you explain why doing that would be a bad idea?

> There will absolutely _not_ be two gmake ports for anything more than
> a suitable deprecation period

I admire your optimism, however experience tells us that once these
types of accomodations get into the tree, they stay there for a long time.

>> My understanding is that there is _currently_ no pressure to get
>> gmake upgraded, so at least exploring the idea of doing it without
>> a kludge seems reasonable to me, although I'm happy to be proven
>> wrong.
>
> The "kludge", in terms of actually testing things to get empirical
> data, rather than hand-waving about the sky falling,

Um, no one said the sky is falling, and you've reacted emotionally to
the term "kludge" rather than answering my question about what the
urgency is to get the update done.

> We have a plan, we're going to get the results
> of that plan, and then do some analysis on it.

And my concern is that the plan seems to have been formulated without
wider input from the community. So I ask again ... what harm can come
from at least trying to fix the broken ports first?


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 14:21 , Doug Barton wrote:
> What I'm suggesting is that the URL for the logs of that run get posted here, along with contacting the maintainers of the affected ports. Then let's see what people have to say about getting them fixed sooner rather than later. Can you explain why doing that would be a bad idea?

Those 50 or so ports are not the complete picture. Some of them are preventing other ports from being built. So, we cycle through an -exp run adding USE_GMAKE=381 (it's not a library or anything, just an executable, and in the context of clean building, only one or the other will exist for a specific port -exp build, so there's no question of interaction) until we have _all_ of the affected ports.

Then the list gets posted somewhere, USE_GMAKE=381 goes active, then there's a period (6-7 months) for folks to clean things up, at which point USE_GMAKE=381 does exactly the same as USE_GMAKE=yes (use gmake-3.82) -- ports that get fixed after this date simply change USE_GMAKE=381 -> USE_GMAKE=yes (cosmetic change only), and a list of known-broken ports can still be determined by grepping for 'USE_GMAKE=381'. If updates to those ports fix them, change USE_GMAKE back to 'yes'.

> I admire your optimism, however experience tells us that once these types of accomodations get into the tree, they stay there for a long time.

There is no issue of optimism about it. gmake-3.82 _will_ be the sole version of GNU make in the tree by (at latest) the end of this year.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 12:52, Ade Lovett wrote:
>
> On Mar 10, 2011, at 14:21 , Doug Barton wrote:
>> What I'm suggesting is that the URL for the logs of that run get
>> posted here, along with contacting the maintainers of the affected
>> ports. Then let's see what people have to say about getting them
>> fixed sooner rather than later. Can you explain why doing that
>> would be a bad idea?
>
> Those 50 or so ports are not the complete picture. Some of them are
> preventing other ports from being built. So, we cycle through an
> -exp run adding USE_GMAKE=381 (it's not a library or anything, just
> an executable, and in the context of clean building, only one or the
> other will exist for a specific port -exp build, so there's no
> question of interaction) until we have _all_ of the affected ports.
>
> Then the list gets posted somewhere,

Great!

> USE_GMAKE=381 goes active,

That's the bit that we disagree on, but your unwillingness to answer the
question I've posed twice now tells me clearly that you are determined
to follow this course of action, so I give up.

>> I admire your optimism, however experience tells us that once these
>> types of accomodations get into the tree, they stay there for a
>> long time.
>
> There is no issue of optimism about it. gmake-3.82 _will_ be the
> sole version of GNU make in the tree by (at latest) the end of this
> year.

You've already slipped your deadline from 6 months firm, to 6-7 months,
now to 9 months in the course of just a few emails. I'd be willing to
wager $BEVERAGE of your choice that we enter 2012 with multiple gmakes
in the ports tree. But like I said, I'd be glad to be proven wrong. :)


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On Thu, Mar 10, 2011 at 02:05:50PM -0600, Ade Lovett wrote:
> Preliminary runs show ~50 ports that break with 3.82, some of them
> unfortunately being dependencies for a reasonable number of others.

For values of "reasonable" in the ~1100 range.

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

Work is now underway to bring GNU make 3.82 into the tree. Sadly, there are a number of rather unfortunate backwards incompatibility issues between this and 3.81 which makes a simple replacement unworkable.

A new port, devel/gmake381 has just been committed to the tree which is a heavily stripped down 3.81 version (just the binary, installed as ${LOCALBASE}/bin/gmake381, no NLS support. It is also currently marked IGNORE and is NOT attached to devel/Makefile. Please do NOT use it directly in any way, shape or form.

The next steps are as follows:

1. A patchset will be implemented, upgrading devel/gmake to 3.82, attaching devel/gmake381 to the build, and extending the USE_GMAKE variable so that a value of 'yes' will continue to use devel/gmake (now 3.82) and '381' will use the older 3.81

2. -exp runs will be iterated over to determine which ports break building with 3.82, and they will be marked as USE_GMAKE=381 to allow them to continue to build. A list of such ports will be maintained and posted.

3. devel/gmake381 will then be marked DEPRECATED with a suitable EXPIRATION_DATE (at least 6 months), at which point it will be removed, and the USE_GMAKE=381 logic also reverted, so that everything will go back to using devel/gmake. Note: it will not be necessary to edit individual port Makefiles back to USE_GMAKE=yes, since the checks for USE_GMAKE only look to see if the variable is defined. This will provide for ease of use (grep -R USE_GMAKE=381 ports/) to pick up any stragglers -- not to mention the fact that they'll most likely be broken in weird and interesting ways.

A followup posting will occur as and when steps (1) and (2) have been completed.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 09:43, Ade Lovett wrote:
> Work is now underway to bring GNU make 3.82 into the tree. Sadly,
> there are a number of rather unfortunate backwards incompatibility
> issues between this and 3.81 which makes a simple replacement
> unworkable.

Can you give us an idea of how many ports we're talking about? Rather
than having 2 gmake ports (which is likely to last for a very long time,
"best laid plans" aside) can we at least explore the idea of fixing
things that are broken to work with 3.82 first? My suggestion is to do
the -exp run, then post here and to maintainers of broken ports directly
and see what a reasonable time frame would be to get things fixed the
right way first.

My understanding is that there is _currently_ no pressure to get gmake
upgraded, so at least exploring the idea of doing it without a kludge
seems reasonable to me, although I'm happy to be proven wrong.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 13:24 , Doug Barton wrote:
> Can you give us an idea of how many ports we're talking about? Rather than having 2 gmake ports (which is likely to last for a very long time, "best laid plans" aside) can we at least explore the idea of fixing things that are broken to work with 3.82 first? My suggestion is to do the -exp run, then post here and to maintainers of broken ports directly and see what a reasonable time frame would be to get things fixed the right way first.

Preliminary runs show ~50 ports that break with 3.82, some of them unfortunately being dependencies for a reasonable number of others. An -exp has already been run, though there were a number of false positives for whatever reason.

There will absolutely _not_ be two gmake ports for anything more than a suitable deprecation period (if it is determined to move ahead) or for perhaps a month (specifically note that devel/gmake381 is marked IGNORE and not attached to the tree, so anyone trying to use it will have ... problems) if it's too much in the way of hacking.

> My understanding is that there is _currently_ no pressure to get gmake upgraded, so at least exploring the idea of doing it without a kludge seems reasonable to me, although I'm happy to be proven wrong.

The "kludge", in terms of actually testing things to get empirical data, rather than hand-waving about the sky falling, is ~4 lines of code in bsd.port.mk. We have a plan, we're going to get the results of that plan, and then do some analysis on it. Working closely with the pkgsrc tree that already _is_ at gmake-3.82

You may find a more productive approach would be to wander over to the gnumake mailing list, and ask why such a massive amount of backwards incompatibility was introduced in a minor version upgrade. Of course, that's entirely your prerogative. In the meantime, I along with a few others are actually going to _do_ the work involved in _testing_ the _possibility_ of this instead of sitting in our armchairs.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 12:05, Ade Lovett wrote:
>
> On Mar 10, 2011, at 13:24 , Doug Barton wrote:
>> Can you give us an idea of how many ports we're talking about?
>> Rather than having 2 gmake ports (which is likely to last for a
>> very long time, "best laid plans" aside) can we at least explore
>> the idea of fixing things that are broken to work with 3.82 first?
>> My suggestion is to do the -exp run, then post here and to
>> maintainers of broken ports directly and see what a reasonable time
>> frame would be to get things fixed the right way first.
>
> Preliminary runs show ~50 ports that break with 3.82, some of them
> unfortunately being dependencies for a reasonable number of others.
> An -exp has already been run, though there were a number of false
> positives for whatever reason.

What I'm suggesting is that the URL for the logs of that run get posted
here, along with contacting the maintainers of the affected ports. Then
let's see what people have to say about getting them fixed sooner rather
than later. Can you explain why doing that would be a bad idea?

> There will absolutely _not_ be two gmake ports for anything more than
> a suitable deprecation period

I admire your optimism, however experience tells us that once these
types of accomodations get into the tree, they stay there for a long time.

>> My understanding is that there is _currently_ no pressure to get
>> gmake upgraded, so at least exploring the idea of doing it without
>> a kludge seems reasonable to me, although I'm happy to be proven
>> wrong.
>
> The "kludge", in terms of actually testing things to get empirical
> data, rather than hand-waving about the sky falling,

Um, no one said the sky is falling, and you've reacted emotionally to
the term "kludge" rather than answering my question about what the
urgency is to get the update done.

> We have a plan, we're going to get the results
> of that plan, and then do some analysis on it.

And my concern is that the plan seems to have been formulated without
wider input from the community. So I ask again ... what harm can come
from at least trying to fix the broken ports first?


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 14:21 , Doug Barton wrote:
> What I'm suggesting is that the URL for the logs of that run get posted here, along with contacting the maintainers of the affected ports. Then let's see what people have to say about getting them fixed sooner rather than later. Can you explain why doing that would be a bad idea?

Those 50 or so ports are not the complete picture. Some of them are preventing other ports from being built. So, we cycle through an -exp run adding USE_GMAKE=381 (it's not a library or anything, just an executable, and in the context of clean building, only one or the other will exist for a specific port -exp build, so there's no question of interaction) until we have _all_ of the affected ports.

Then the list gets posted somewhere, USE_GMAKE=381 goes active, then there's a period (6-7 months) for folks to clean things up, at which point USE_GMAKE=381 does exactly the same as USE_GMAKE=yes (use gmake-3.82) -- ports that get fixed after this date simply change USE_GMAKE=381 -> USE_GMAKE=yes (cosmetic change only), and a list of known-broken ports can still be determined by grepping for 'USE_GMAKE=381'. If updates to those ports fix them, change USE_GMAKE back to 'yes'.

> I admire your optimism, however experience tells us that once these types of accomodations get into the tree, they stay there for a long time.

There is no issue of optimism about it. gmake-3.82 _will_ be the sole version of GNU make in the tree by (at latest) the end of this year.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 12:52, Ade Lovett wrote:
>
> On Mar 10, 2011, at 14:21 , Doug Barton wrote:
>> What I'm suggesting is that the URL for the logs of that run get
>> posted here, along with contacting the maintainers of the affected
>> ports. Then let's see what people have to say about getting them
>> fixed sooner rather than later. Can you explain why doing that
>> would be a bad idea?
>
> Those 50 or so ports are not the complete picture. Some of them are
> preventing other ports from being built. So, we cycle through an
> -exp run adding USE_GMAKE=381 (it's not a library or anything, just
> an executable, and in the context of clean building, only one or the
> other will exist for a specific port -exp build, so there's no
> question of interaction) until we have _all_ of the affected ports.
>
> Then the list gets posted somewhere,

Great!

> USE_GMAKE=381 goes active,

That's the bit that we disagree on, but your unwillingness to answer the
question I've posed twice now tells me clearly that you are determined
to follow this course of action, so I give up.

>> I admire your optimism, however experience tells us that once these
>> types of accomodations get into the tree, they stay there for a
>> long time.
>
> There is no issue of optimism about it. gmake-3.82 _will_ be the
> sole version of GNU make in the tree by (at latest) the end of this
> year.

You've already slipped your deadline from 6 months firm, to 6-7 months,
now to 9 months in the course of just a few emails. I'd be willing to
wager $BEVERAGE of your choice that we enter 2012 with multiple gmakes
in the ports tree. But like I said, I'd be glad to be proven wrong. :)


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On Thu, Mar 10, 2011 at 02:05:50PM -0600, Ade Lovett wrote:
> Preliminary runs show ~50 ports that break with 3.82, some of them
> unfortunately being dependencies for a reasonable number of others.

For values of "reasonable" in the ~1100 range.

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On Mar 10, 2011, at 14:21 , Doug Barton wrote:
> I admire your optimism, however experience tells us that once these
> types of accomodations get into the tree, they stay there for a long
> time.

Here's what I have on my system:

devel/autoconf
devel/autoconf213
devel/automake
devel/automake14
devel/autotools
devel/libtool

(That's not counting the -wrapper convenience ports.)

So: one antiquated version each of autoconf and automake.

$ dependson autoconf-2.1 | wc -l
73
$ dependson autoconf | wc -l
910
$ dependson automake-1.4 | wc -l
31
$ dependson automake | wc -l
325

('dependson' is just a script that greps INDEX.)

Summary: there used to be a lot of auto* ports. There aren't, now.

Anyone interested in looking through the sordid details can find them at
http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/ .

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

Work is now underway to bring GNU make 3.82 into the tree. Sadly, there are a number of rather unfortunate backwards incompatibility issues between this and 3.81 which makes a simple replacement unworkable.

A new port, devel/gmake381 has just been committed to the tree which is a heavily stripped down 3.81 version (just the binary, installed as ${LOCALBASE}/bin/gmake381, no NLS support. It is also currently marked IGNORE and is NOT attached to devel/Makefile. Please do NOT use it directly in any way, shape or form.

The next steps are as follows:

1. A patchset will be implemented, upgrading devel/gmake to 3.82, attaching devel/gmake381 to the build, and extending the USE_GMAKE variable so that a value of 'yes' will continue to use devel/gmake (now 3.82) and '381' will use the older 3.81

2. -exp runs will be iterated over to determine which ports break building with 3.82, and they will be marked as USE_GMAKE=381 to allow them to continue to build. A list of such ports will be maintained and posted.

3. devel/gmake381 will then be marked DEPRECATED with a suitable EXPIRATION_DATE (at least 6 months), at which point it will be removed, and the USE_GMAKE=381 logic also reverted, so that everything will go back to using devel/gmake. Note: it will not be necessary to edit individual port Makefiles back to USE_GMAKE=yes, since the checks for USE_GMAKE only look to see if the variable is defined. This will provide for ease of use (grep -R USE_GMAKE=381 ports/) to pick up any stragglers -- not to mention the fact that they'll most likely be broken in weird and interesting ways.

A followup posting will occur as and when steps (1) and (2) have been completed.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 09:43, Ade Lovett wrote:
> Work is now underway to bring GNU make 3.82 into the tree. Sadly,
> there are a number of rather unfortunate backwards incompatibility
> issues between this and 3.81 which makes a simple replacement
> unworkable.

Can you give us an idea of how many ports we're talking about? Rather
than having 2 gmake ports (which is likely to last for a very long time,
"best laid plans" aside) can we at least explore the idea of fixing
things that are broken to work with 3.82 first? My suggestion is to do
the -exp run, then post here and to maintainers of broken ports directly
and see what a reasonable time frame would be to get things fixed the
right way first.

My understanding is that there is _currently_ no pressure to get gmake
upgraded, so at least exploring the idea of doing it without a kludge
seems reasonable to me, although I'm happy to be proven wrong.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 13:24 , Doug Barton wrote:
> Can you give us an idea of how many ports we're talking about? Rather than having 2 gmake ports (which is likely to last for a very long time, "best laid plans" aside) can we at least explore the idea of fixing things that are broken to work with 3.82 first? My suggestion is to do the -exp run, then post here and to maintainers of broken ports directly and see what a reasonable time frame would be to get things fixed the right way first.

Preliminary runs show ~50 ports that break with 3.82, some of them unfortunately being dependencies for a reasonable number of others. An -exp has already been run, though there were a number of false positives for whatever reason.

There will absolutely _not_ be two gmake ports for anything more than a suitable deprecation period (if it is determined to move ahead) or for perhaps a month (specifically note that devel/gmake381 is marked IGNORE and not attached to the tree, so anyone trying to use it will have ... problems) if it's too much in the way of hacking.

> My understanding is that there is _currently_ no pressure to get gmake upgraded, so at least exploring the idea of doing it without a kludge seems reasonable to me, although I'm happy to be proven wrong.

The "kludge", in terms of actually testing things to get empirical data, rather than hand-waving about the sky falling, is ~4 lines of code in bsd.port.mk. We have a plan, we're going to get the results of that plan, and then do some analysis on it. Working closely with the pkgsrc tree that already _is_ at gmake-3.82

You may find a more productive approach would be to wander over to the gnumake mailing list, and ask why such a massive amount of backwards incompatibility was introduced in a minor version upgrade. Of course, that's entirely your prerogative. In the meantime, I along with a few others are actually going to _do_ the work involved in _testing_ the _possibility_ of this instead of sitting in our armchairs.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 12:05, Ade Lovett wrote:
>
> On Mar 10, 2011, at 13:24 , Doug Barton wrote:
>> Can you give us an idea of how many ports we're talking about?
>> Rather than having 2 gmake ports (which is likely to last for a
>> very long time, "best laid plans" aside) can we at least explore
>> the idea of fixing things that are broken to work with 3.82 first?
>> My suggestion is to do the -exp run, then post here and to
>> maintainers of broken ports directly and see what a reasonable time
>> frame would be to get things fixed the right way first.
>
> Preliminary runs show ~50 ports that break with 3.82, some of them
> unfortunately being dependencies for a reasonable number of others.
> An -exp has already been run, though there were a number of false
> positives for whatever reason.

What I'm suggesting is that the URL for the logs of that run get posted
here, along with contacting the maintainers of the affected ports. Then
let's see what people have to say about getting them fixed sooner rather
than later. Can you explain why doing that would be a bad idea?

> There will absolutely _not_ be two gmake ports for anything more than
> a suitable deprecation period

I admire your optimism, however experience tells us that once these
types of accomodations get into the tree, they stay there for a long time.

>> My understanding is that there is _currently_ no pressure to get
>> gmake upgraded, so at least exploring the idea of doing it without
>> a kludge seems reasonable to me, although I'm happy to be proven
>> wrong.
>
> The "kludge", in terms of actually testing things to get empirical
> data, rather than hand-waving about the sky falling,

Um, no one said the sky is falling, and you've reacted emotionally to
the term "kludge" rather than answering my question about what the
urgency is to get the update done.

> We have a plan, we're going to get the results
> of that plan, and then do some analysis on it.

And my concern is that the plan seems to have been formulated without
wider input from the community. So I ask again ... what harm can come
from at least trying to fix the broken ports first?


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 14:21 , Doug Barton wrote:
> What I'm suggesting is that the URL for the logs of that run get posted here, along with contacting the maintainers of the affected ports. Then let's see what people have to say about getting them fixed sooner rather than later. Can you explain why doing that would be a bad idea?

Those 50 or so ports are not the complete picture. Some of them are preventing other ports from being built. So, we cycle through an -exp run adding USE_GMAKE=381 (it's not a library or anything, just an executable, and in the context of clean building, only one or the other will exist for a specific port -exp build, so there's no question of interaction) until we have _all_ of the affected ports.

Then the list gets posted somewhere, USE_GMAKE=381 goes active, then there's a period (6-7 months) for folks to clean things up, at which point USE_GMAKE=381 does exactly the same as USE_GMAKE=yes (use gmake-3.82) -- ports that get fixed after this date simply change USE_GMAKE=381 -> USE_GMAKE=yes (cosmetic change only), and a list of known-broken ports can still be determined by grepping for 'USE_GMAKE=381'. If updates to those ports fix them, change USE_GMAKE back to 'yes'.

> I admire your optimism, however experience tells us that once these types of accomodations get into the tree, they stay there for a long time.

There is no issue of optimism about it. gmake-3.82 _will_ be the sole version of GNU make in the tree by (at latest) the end of this year.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 12:52, Ade Lovett wrote:
>
> On Mar 10, 2011, at 14:21 , Doug Barton wrote:
>> What I'm suggesting is that the URL for the logs of that run get
>> posted here, along with contacting the maintainers of the affected
>> ports. Then let's see what people have to say about getting them
>> fixed sooner rather than later. Can you explain why doing that
>> would be a bad idea?
>
> Those 50 or so ports are not the complete picture. Some of them are
> preventing other ports from being built. So, we cycle through an
> -exp run adding USE_GMAKE=381 (it's not a library or anything, just
> an executable, and in the context of clean building, only one or the
> other will exist for a specific port -exp build, so there's no
> question of interaction) until we have _all_ of the affected ports.
>
> Then the list gets posted somewhere,

Great!

> USE_GMAKE=381 goes active,

That's the bit that we disagree on, but your unwillingness to answer the
question I've posed twice now tells me clearly that you are determined
to follow this course of action, so I give up.

>> I admire your optimism, however experience tells us that once these
>> types of accomodations get into the tree, they stay there for a
>> long time.
>
> There is no issue of optimism about it. gmake-3.82 _will_ be the
> sole version of GNU make in the tree by (at latest) the end of this
> year.

You've already slipped your deadline from 6 months firm, to 6-7 months,
now to 9 months in the course of just a few emails. I'd be willing to
wager $BEVERAGE of your choice that we enter 2012 with multiple gmakes
in the ports tree. But like I said, I'd be glad to be proven wrong. :)


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On Thu, Mar 10, 2011 at 02:05:50PM -0600, Ade Lovett wrote:
> Preliminary runs show ~50 ports that break with 3.82, some of them
> unfortunately being dependencies for a reasonable number of others.

For values of "reasonable" in the ~1100 range.

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On Mar 10, 2011, at 14:21 , Doug Barton wrote:
> I admire your optimism, however experience tells us that once these
> types of accomodations get into the tree, they stay there for a long
> time.

Here's what I have on my system:

devel/autoconf
devel/autoconf213
devel/automake
devel/automake14
devel/autotools
devel/libtool

(That's not counting the -wrapper convenience ports.)

So: one antiquated version each of autoconf and automake.

$ dependson autoconf-2.1 | wc -l
73
$ dependson autoconf | wc -l
910
$ dependson automake-1.4 | wc -l
31
$ dependson automake | wc -l
325

('dependson' is just a script that greps INDEX.)

Summary: there used to be a lot of auto* ports. There aren't, now.

Anyone interested in looking through the sordid details can find them at
http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/ .

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

Mark Linimon writes:

> Summary: there used to be a lot of auto* ports. There aren't,
> now.

Am I correct in remembering the "used to be" period covered
2+(+) years?


Robert "sure seemed like it :-)" Huff


_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

Work is now underway to bring GNU make 3.82 into the tree. Sadly, there are a number of rather unfortunate backwards incompatibility issues between this and 3.81 which makes a simple replacement unworkable.

A new port, devel/gmake381 has just been committed to the tree which is a heavily stripped down 3.81 version (just the binary, installed as ${LOCALBASE}/bin/gmake381, no NLS support. It is also currently marked IGNORE and is NOT attached to devel/Makefile. Please do NOT use it directly in any way, shape or form.

The next steps are as follows:

1. A patchset will be implemented, upgrading devel/gmake to 3.82, attaching devel/gmake381 to the build, and extending the USE_GMAKE variable so that a value of 'yes' will continue to use devel/gmake (now 3.82) and '381' will use the older 3.81

2. -exp runs will be iterated over to determine which ports break building with 3.82, and they will be marked as USE_GMAKE=381 to allow them to continue to build. A list of such ports will be maintained and posted.

3. devel/gmake381 will then be marked DEPRECATED with a suitable EXPIRATION_DATE (at least 6 months), at which point it will be removed, and the USE_GMAKE=381 logic also reverted, so that everything will go back to using devel/gmake. Note: it will not be necessary to edit individual port Makefiles back to USE_GMAKE=yes, since the checks for USE_GMAKE only look to see if the variable is defined. This will provide for ease of use (grep -R USE_GMAKE=381 ports/) to pick up any stragglers -- not to mention the fact that they'll most likely be broken in weird and interesting ways.

A followup posting will occur as and when steps (1) and (2) have been completed.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 09:43, Ade Lovett wrote:
> Work is now underway to bring GNU make 3.82 into the tree. Sadly,
> there are a number of rather unfortunate backwards incompatibility
> issues between this and 3.81 which makes a simple replacement
> unworkable.

Can you give us an idea of how many ports we're talking about? Rather
than having 2 gmake ports (which is likely to last for a very long time,
"best laid plans" aside) can we at least explore the idea of fixing
things that are broken to work with 3.82 first? My suggestion is to do
the -exp run, then post here and to maintainers of broken ports directly
and see what a reasonable time frame would be to get things fixed the
right way first.

My understanding is that there is _currently_ no pressure to get gmake
upgraded, so at least exploring the idea of doing it without a kludge
seems reasonable to me, although I'm happy to be proven wrong.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 13:24 , Doug Barton wrote:
> Can you give us an idea of how many ports we're talking about? Rather than having 2 gmake ports (which is likely to last for a very long time, "best laid plans" aside) can we at least explore the idea of fixing things that are broken to work with 3.82 first? My suggestion is to do the -exp run, then post here and to maintainers of broken ports directly and see what a reasonable time frame would be to get things fixed the right way first.

Preliminary runs show ~50 ports that break with 3.82, some of them unfortunately being dependencies for a reasonable number of others. An -exp has already been run, though there were a number of false positives for whatever reason.

There will absolutely _not_ be two gmake ports for anything more than a suitable deprecation period (if it is determined to move ahead) or for perhaps a month (specifically note that devel/gmake381 is marked IGNORE and not attached to the tree, so anyone trying to use it will have ... problems) if it's too much in the way of hacking.

> My understanding is that there is _currently_ no pressure to get gmake upgraded, so at least exploring the idea of doing it without a kludge seems reasonable to me, although I'm happy to be proven wrong.

The "kludge", in terms of actually testing things to get empirical data, rather than hand-waving about the sky falling, is ~4 lines of code in bsd.port.mk. We have a plan, we're going to get the results of that plan, and then do some analysis on it. Working closely with the pkgsrc tree that already _is_ at gmake-3.82

You may find a more productive approach would be to wander over to the gnumake mailing list, and ask why such a massive amount of backwards incompatibility was introduced in a minor version upgrade. Of course, that's entirely your prerogative. In the meantime, I along with a few others are actually going to _do_ the work involved in _testing_ the _possibility_ of this instead of sitting in our armchairs.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 12:05, Ade Lovett wrote:
>
> On Mar 10, 2011, at 13:24 , Doug Barton wrote:
>> Can you give us an idea of how many ports we're talking about?
>> Rather than having 2 gmake ports (which is likely to last for a
>> very long time, "best laid plans" aside) can we at least explore
>> the idea of fixing things that are broken to work with 3.82 first?
>> My suggestion is to do the -exp run, then post here and to
>> maintainers of broken ports directly and see what a reasonable time
>> frame would be to get things fixed the right way first.
>
> Preliminary runs show ~50 ports that break with 3.82, some of them
> unfortunately being dependencies for a reasonable number of others.
> An -exp has already been run, though there were a number of false
> positives for whatever reason.

What I'm suggesting is that the URL for the logs of that run get posted
here, along with contacting the maintainers of the affected ports. Then
let's see what people have to say about getting them fixed sooner rather
than later. Can you explain why doing that would be a bad idea?

> There will absolutely _not_ be two gmake ports for anything more than
> a suitable deprecation period

I admire your optimism, however experience tells us that once these
types of accomodations get into the tree, they stay there for a long time.

>> My understanding is that there is _currently_ no pressure to get
>> gmake upgraded, so at least exploring the idea of doing it without
>> a kludge seems reasonable to me, although I'm happy to be proven
>> wrong.
>
> The "kludge", in terms of actually testing things to get empirical
> data, rather than hand-waving about the sky falling,

Um, no one said the sky is falling, and you've reacted emotionally to
the term "kludge" rather than answering my question about what the
urgency is to get the update done.

> We have a plan, we're going to get the results
> of that plan, and then do some analysis on it.

And my concern is that the plan seems to have been formulated without
wider input from the community. So I ask again ... what harm can come
from at least trying to fix the broken ports first?


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 14:21 , Doug Barton wrote:
> What I'm suggesting is that the URL for the logs of that run get posted here, along with contacting the maintainers of the affected ports. Then let's see what people have to say about getting them fixed sooner rather than later. Can you explain why doing that would be a bad idea?

Those 50 or so ports are not the complete picture. Some of them are preventing other ports from being built. So, we cycle through an -exp run adding USE_GMAKE=381 (it's not a library or anything, just an executable, and in the context of clean building, only one or the other will exist for a specific port -exp build, so there's no question of interaction) until we have _all_ of the affected ports.

Then the list gets posted somewhere, USE_GMAKE=381 goes active, then there's a period (6-7 months) for folks to clean things up, at which point USE_GMAKE=381 does exactly the same as USE_GMAKE=yes (use gmake-3.82) -- ports that get fixed after this date simply change USE_GMAKE=381 -> USE_GMAKE=yes (cosmetic change only), and a list of known-broken ports can still be determined by grepping for 'USE_GMAKE=381'. If updates to those ports fix them, change USE_GMAKE back to 'yes'.

> I admire your optimism, however experience tells us that once these types of accomodations get into the tree, they stay there for a long time.

There is no issue of optimism about it. gmake-3.82 _will_ be the sole version of GNU make in the tree by (at latest) the end of this year.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 12:52, Ade Lovett wrote:
>
> On Mar 10, 2011, at 14:21 , Doug Barton wrote:
>> What I'm suggesting is that the URL for the logs of that run get
>> posted here, along with contacting the maintainers of the affected
>> ports. Then let's see what people have to say about getting them
>> fixed sooner rather than later. Can you explain why doing that
>> would be a bad idea?
>
> Those 50 or so ports are not the complete picture. Some of them are
> preventing other ports from being built. So, we cycle through an
> -exp run adding USE_GMAKE=381 (it's not a library or anything, just
> an executable, and in the context of clean building, only one or the
> other will exist for a specific port -exp build, so there's no
> question of interaction) until we have _all_ of the affected ports.
>
> Then the list gets posted somewhere,

Great!

> USE_GMAKE=381 goes active,

That's the bit that we disagree on, but your unwillingness to answer the
question I've posed twice now tells me clearly that you are determined
to follow this course of action, so I give up.

>> I admire your optimism, however experience tells us that once these
>> types of accomodations get into the tree, they stay there for a
>> long time.
>
> There is no issue of optimism about it. gmake-3.82 _will_ be the
> sole version of GNU make in the tree by (at latest) the end of this
> year.

You've already slipped your deadline from 6 months firm, to 6-7 months,
now to 9 months in the course of just a few emails. I'd be willing to
wager $BEVERAGE of your choice that we enter 2012 with multiple gmakes
in the ports tree. But like I said, I'd be glad to be proven wrong. :)


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On Thu, Mar 10, 2011 at 02:05:50PM -0600, Ade Lovett wrote:
> Preliminary runs show ~50 ports that break with 3.82, some of them
> unfortunately being dependencies for a reasonable number of others.

For values of "reasonable" in the ~1100 range.

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On Mar 10, 2011, at 14:21 , Doug Barton wrote:
> I admire your optimism, however experience tells us that once these
> types of accomodations get into the tree, they stay there for a long
> time.

Here's what I have on my system:

devel/autoconf
devel/autoconf213
devel/automake
devel/automake14
devel/autotools
devel/libtool

(That's not counting the -wrapper convenience ports.)

So: one antiquated version each of autoconf and automake.

$ dependson autoconf-2.1 | wc -l
73
$ dependson autoconf | wc -l
910
$ dependson automake-1.4 | wc -l
31
$ dependson automake | wc -l
325

('dependson' is just a script that greps INDEX.)

Summary: there used to be a lot of auto* ports. There aren't, now.

Anyone interested in looking through the sordid details can find them at
http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/ .

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

Mark Linimon writes:

> Summary: there used to be a lot of auto* ports. There aren't,
> now.

Am I correct in remembering the "used to be" period covered
2+(+) years?


Robert "sure seemed like it :-)" Huff


_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 15:54, Mark Linimon wrote:
> On Mar 10, 2011, at 14:21 , Doug Barton wrote:
>> I admire your optimism, however experience tells us that once these
>> types of accomodations get into the tree, they stay there for a long
>> time.
>
> Here's what I have on my system:
>
> devel/autoconf
> devel/autoconf213
> devel/automake
> devel/automake14
> devel/autotools
> devel/libtool
>
> (That's not counting the -wrapper convenience ports.)

[snip]

> Summary: there used to be a lot of auto* ports. There aren't, now.

First, my point was not "there are going to be a lot of gmake ports," my
point was, "there will be >1 for a long time after it's split into >1."
You have now proved my point, thanks. While we're discussing anecdotal
evidence:

autoconf-2.13.000227_6
autoconf-2.68

automake-1.4.6_6
automake-1.11.1

But that's only because I periodically do 'pkg_delete auto*' so this is
not really representative.

Meanwhile, this is why I reacted so strongly on IRC when it was
suggested that bifurcating gmake was the way to go. I was 100% certain
at the time that it was a foregone conclusion.

So maybe you will take a stab at my real question, what is the urgency
in upgrading gmake that prevents "fix the broken ports first" as an
option to at least explore? And while we're at it, if you have already
done the iterative -exp runs to get the 1100 ports figure, where are
those logs?


Thanks,

Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

Work is now underway to bring GNU make 3.82 into the tree. Sadly, there are a number of rather unfortunate backwards incompatibility issues between this and 3.81 which makes a simple replacement unworkable.

A new port, devel/gmake381 has just been committed to the tree which is a heavily stripped down 3.81 version (just the binary, installed as ${LOCALBASE}/bin/gmake381, no NLS support. It is also currently marked IGNORE and is NOT attached to devel/Makefile. Please do NOT use it directly in any way, shape or form.

The next steps are as follows:

1. A patchset will be implemented, upgrading devel/gmake to 3.82, attaching devel/gmake381 to the build, and extending the USE_GMAKE variable so that a value of 'yes' will continue to use devel/gmake (now 3.82) and '381' will use the older 3.81

2. -exp runs will be iterated over to determine which ports break building with 3.82, and they will be marked as USE_GMAKE=381 to allow them to continue to build. A list of such ports will be maintained and posted.

3. devel/gmake381 will then be marked DEPRECATED with a suitable EXPIRATION_DATE (at least 6 months), at which point it will be removed, and the USE_GMAKE=381 logic also reverted, so that everything will go back to using devel/gmake. Note: it will not be necessary to edit individual port Makefiles back to USE_GMAKE=yes, since the checks for USE_GMAKE only look to see if the variable is defined. This will provide for ease of use (grep -R USE_GMAKE=381 ports/) to pick up any stragglers -- not to mention the fact that they'll most likely be broken in weird and interesting ways.

A followup posting will occur as and when steps (1) and (2) have been completed.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 09:43, Ade Lovett wrote:
> Work is now underway to bring GNU make 3.82 into the tree. Sadly,
> there are a number of rather unfortunate backwards incompatibility
> issues between this and 3.81 which makes a simple replacement
> unworkable.

Can you give us an idea of how many ports we're talking about? Rather
than having 2 gmake ports (which is likely to last for a very long time,
"best laid plans" aside) can we at least explore the idea of fixing
things that are broken to work with 3.82 first? My suggestion is to do
the -exp run, then post here and to maintainers of broken ports directly
and see what a reasonable time frame would be to get things fixed the
right way first.

My understanding is that there is _currently_ no pressure to get gmake
upgraded, so at least exploring the idea of doing it without a kludge
seems reasonable to me, although I'm happy to be proven wrong.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 13:24 , Doug Barton wrote:
> Can you give us an idea of how many ports we're talking about? Rather than having 2 gmake ports (which is likely to last for a very long time, "best laid plans" aside) can we at least explore the idea of fixing things that are broken to work with 3.82 first? My suggestion is to do the -exp run, then post here and to maintainers of broken ports directly and see what a reasonable time frame would be to get things fixed the right way first.

Preliminary runs show ~50 ports that break with 3.82, some of them unfortunately being dependencies for a reasonable number of others. An -exp has already been run, though there were a number of false positives for whatever reason.

There will absolutely _not_ be two gmake ports for anything more than a suitable deprecation period (if it is determined to move ahead) or for perhaps a month (specifically note that devel/gmake381 is marked IGNORE and not attached to the tree, so anyone trying to use it will have ... problems) if it's too much in the way of hacking.

> My understanding is that there is _currently_ no pressure to get gmake upgraded, so at least exploring the idea of doing it without a kludge seems reasonable to me, although I'm happy to be proven wrong.

The "kludge", in terms of actually testing things to get empirical data, rather than hand-waving about the sky falling, is ~4 lines of code in bsd.port.mk. We have a plan, we're going to get the results of that plan, and then do some analysis on it. Working closely with the pkgsrc tree that already _is_ at gmake-3.82

You may find a more productive approach would be to wander over to the gnumake mailing list, and ask why such a massive amount of backwards incompatibility was introduced in a minor version upgrade. Of course, that's entirely your prerogative. In the meantime, I along with a few others are actually going to _do_ the work involved in _testing_ the _possibility_ of this instead of sitting in our armchairs.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 12:05, Ade Lovett wrote:
>
> On Mar 10, 2011, at 13:24 , Doug Barton wrote:
>> Can you give us an idea of how many ports we're talking about?
>> Rather than having 2 gmake ports (which is likely to last for a
>> very long time, "best laid plans" aside) can we at least explore
>> the idea of fixing things that are broken to work with 3.82 first?
>> My suggestion is to do the -exp run, then post here and to
>> maintainers of broken ports directly and see what a reasonable time
>> frame would be to get things fixed the right way first.
>
> Preliminary runs show ~50 ports that break with 3.82, some of them
> unfortunately being dependencies for a reasonable number of others.
> An -exp has already been run, though there were a number of false
> positives for whatever reason.

What I'm suggesting is that the URL for the logs of that run get posted
here, along with contacting the maintainers of the affected ports. Then
let's see what people have to say about getting them fixed sooner rather
than later. Can you explain why doing that would be a bad idea?

> There will absolutely _not_ be two gmake ports for anything more than
> a suitable deprecation period

I admire your optimism, however experience tells us that once these
types of accomodations get into the tree, they stay there for a long time.

>> My understanding is that there is _currently_ no pressure to get
>> gmake upgraded, so at least exploring the idea of doing it without
>> a kludge seems reasonable to me, although I'm happy to be proven
>> wrong.
>
> The "kludge", in terms of actually testing things to get empirical
> data, rather than hand-waving about the sky falling,

Um, no one said the sky is falling, and you've reacted emotionally to
the term "kludge" rather than answering my question about what the
urgency is to get the update done.

> We have a plan, we're going to get the results
> of that plan, and then do some analysis on it.

And my concern is that the plan seems to have been formulated without
wider input from the community. So I ask again ... what harm can come
from at least trying to fix the broken ports first?


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 14:21 , Doug Barton wrote:
> What I'm suggesting is that the URL for the logs of that run get posted here, along with contacting the maintainers of the affected ports. Then let's see what people have to say about getting them fixed sooner rather than later. Can you explain why doing that would be a bad idea?

Those 50 or so ports are not the complete picture. Some of them are preventing other ports from being built. So, we cycle through an -exp run adding USE_GMAKE=381 (it's not a library or anything, just an executable, and in the context of clean building, only one or the other will exist for a specific port -exp build, so there's no question of interaction) until we have _all_ of the affected ports.

Then the list gets posted somewhere, USE_GMAKE=381 goes active, then there's a period (6-7 months) for folks to clean things up, at which point USE_GMAKE=381 does exactly the same as USE_GMAKE=yes (use gmake-3.82) -- ports that get fixed after this date simply change USE_GMAKE=381 -> USE_GMAKE=yes (cosmetic change only), and a list of known-broken ports can still be determined by grepping for 'USE_GMAKE=381'. If updates to those ports fix them, change USE_GMAKE back to 'yes'.

> I admire your optimism, however experience tells us that once these types of accomodations get into the tree, they stay there for a long time.

There is no issue of optimism about it. gmake-3.82 _will_ be the sole version of GNU make in the tree by (at latest) the end of this year.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 12:52, Ade Lovett wrote:
>
> On Mar 10, 2011, at 14:21 , Doug Barton wrote:
>> What I'm suggesting is that the URL for the logs of that run get
>> posted here, along with contacting the maintainers of the affected
>> ports. Then let's see what people have to say about getting them
>> fixed sooner rather than later. Can you explain why doing that
>> would be a bad idea?
>
> Those 50 or so ports are not the complete picture. Some of them are
> preventing other ports from being built. So, we cycle through an
> -exp run adding USE_GMAKE=381 (it's not a library or anything, just
> an executable, and in the context of clean building, only one or the
> other will exist for a specific port -exp build, so there's no
> question of interaction) until we have _all_ of the affected ports.
>
> Then the list gets posted somewhere,

Great!

> USE_GMAKE=381 goes active,

That's the bit that we disagree on, but your unwillingness to answer the
question I've posed twice now tells me clearly that you are determined
to follow this course of action, so I give up.

>> I admire your optimism, however experience tells us that once these
>> types of accomodations get into the tree, they stay there for a
>> long time.
>
> There is no issue of optimism about it. gmake-3.82 _will_ be the
> sole version of GNU make in the tree by (at latest) the end of this
> year.

You've already slipped your deadline from 6 months firm, to 6-7 months,
now to 9 months in the course of just a few emails. I'd be willing to
wager $BEVERAGE of your choice that we enter 2012 with multiple gmakes
in the ports tree. But like I said, I'd be glad to be proven wrong. :)


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On Thu, Mar 10, 2011 at 02:05:50PM -0600, Ade Lovett wrote:
> Preliminary runs show ~50 ports that break with 3.82, some of them
> unfortunately being dependencies for a reasonable number of others.

For values of "reasonable" in the ~1100 range.

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On Mar 10, 2011, at 14:21 , Doug Barton wrote:
> I admire your optimism, however experience tells us that once these
> types of accomodations get into the tree, they stay there for a long
> time.

Here's what I have on my system:

devel/autoconf
devel/autoconf213
devel/automake
devel/automake14
devel/autotools
devel/libtool

(That's not counting the -wrapper convenience ports.)

So: one antiquated version each of autoconf and automake.

$ dependson autoconf-2.1 | wc -l
73
$ dependson autoconf | wc -l
910
$ dependson automake-1.4 | wc -l
31
$ dependson automake | wc -l
325

('dependson' is just a script that greps INDEX.)

Summary: there used to be a lot of auto* ports. There aren't, now.

Anyone interested in looking through the sordid details can find them at
http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/ .

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

Mark Linimon writes:

> Summary: there used to be a lot of auto* ports. There aren't,
> now.

Am I correct in remembering the "used to be" period covered
2+(+) years?


Robert "sure seemed like it :-)" Huff


_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 15:54, Mark Linimon wrote:
> On Mar 10, 2011, at 14:21 , Doug Barton wrote:
>> I admire your optimism, however experience tells us that once these
>> types of accomodations get into the tree, they stay there for a long
>> time.
>
> Here's what I have on my system:
>
> devel/autoconf
> devel/autoconf213
> devel/automake
> devel/automake14
> devel/autotools
> devel/libtool
>
> (That's not counting the -wrapper convenience ports.)

[snip]

> Summary: there used to be a lot of auto* ports. There aren't, now.

First, my point was not "there are going to be a lot of gmake ports," my
point was, "there will be >1 for a long time after it's split into >1."
You have now proved my point, thanks. While we're discussing anecdotal
evidence:

autoconf-2.13.000227_6
autoconf-2.68

automake-1.4.6_6
automake-1.11.1

But that's only because I periodically do 'pkg_delete auto*' so this is
not really representative.

Meanwhile, this is why I reacted so strongly on IRC when it was
suggested that bifurcating gmake was the way to go. I was 100% certain
at the time that it was a foregone conclusion.

So maybe you will take a stab at my real question, what is the urgency
in upgrading gmake that prevents "fix the broken ports first" as an
option to at least explore? And while we're at it, if you have already
done the iterative -exp runs to get the 1100 ports figure, where are
those logs?


Thanks,

Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 18:09 , Doug Barton wrote:
> First, my point was not "there are going to be a lot of gmake ports," my point was, "there will be >1 for a long time after it's split into >1." You have now proved my point, thanks.

Apples and oranges, my friend. Given the sheer amount of stuff we have in ports/, there is a small amount of stuff that hasn't been updated in forever, nor ever will be, requiring the "legacy" autoconf-2.13/automake-1.4

Go look up pkgsrc. Or any Linux distribution. You'll find both of them lying there. I'd love to nuke them, and those ports that require them to build, but people tend to get upset when Really Important Application (sic) gets removed from under them.

As for the rest of your post. It's the usual diatribe. If you think you can do better, by all means, step up to the plate and actually _do_ something. Like yours truly has done reducing libtool to 1 version, and autoconf/automake to 2 versions (legacy and current).

Unless you're prepared to step up to the plate, offer alternate _concrete_ plans (as I have already done) and are willing to spend considerable brain and cpu cycles to get to the desired solution, you have no right to question what _is_ being done by those that _are_ doing it.

This is _not_ a democracy. The war cry of "Patches Welcome" should be obvious in that fact.

So. Let's see your patches. Seriously. Hell, if someone else takes this on (and note, it is only a matter of time before something fundamental _requires_ GNU make 3.82, so we can't just bury our heads in the sand), go for it.

Didn't think so.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

Work is now underway to bring GNU make 3.82 into the tree. Sadly, there are a number of rather unfortunate backwards incompatibility issues between this and 3.81 which makes a simple replacement unworkable.

A new port, devel/gmake381 has just been committed to the tree which is a heavily stripped down 3.81 version (just the binary, installed as ${LOCALBASE}/bin/gmake381, no NLS support. It is also currently marked IGNORE and is NOT attached to devel/Makefile. Please do NOT use it directly in any way, shape or form.

The next steps are as follows:

1. A patchset will be implemented, upgrading devel/gmake to 3.82, attaching devel/gmake381 to the build, and extending the USE_GMAKE variable so that a value of 'yes' will continue to use devel/gmake (now 3.82) and '381' will use the older 3.81

2. -exp runs will be iterated over to determine which ports break building with 3.82, and they will be marked as USE_GMAKE=381 to allow them to continue to build. A list of such ports will be maintained and posted.

3. devel/gmake381 will then be marked DEPRECATED with a suitable EXPIRATION_DATE (at least 6 months), at which point it will be removed, and the USE_GMAKE=381 logic also reverted, so that everything will go back to using devel/gmake. Note: it will not be necessary to edit individual port Makefiles back to USE_GMAKE=yes, since the checks for USE_GMAKE only look to see if the variable is defined. This will provide for ease of use (grep -R USE_GMAKE=381 ports/) to pick up any stragglers -- not to mention the fact that they'll most likely be broken in weird and interesting ways.

A followup posting will occur as and when steps (1) and (2) have been completed.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 09:43, Ade Lovett wrote:
> Work is now underway to bring GNU make 3.82 into the tree. Sadly,
> there are a number of rather unfortunate backwards incompatibility
> issues between this and 3.81 which makes a simple replacement
> unworkable.

Can you give us an idea of how many ports we're talking about? Rather
than having 2 gmake ports (which is likely to last for a very long time,
"best laid plans" aside) can we at least explore the idea of fixing
things that are broken to work with 3.82 first? My suggestion is to do
the -exp run, then post here and to maintainers of broken ports directly
and see what a reasonable time frame would be to get things fixed the
right way first.

My understanding is that there is _currently_ no pressure to get gmake
upgraded, so at least exploring the idea of doing it without a kludge
seems reasonable to me, although I'm happy to be proven wrong.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 13:24 , Doug Barton wrote:
> Can you give us an idea of how many ports we're talking about? Rather than having 2 gmake ports (which is likely to last for a very long time, "best laid plans" aside) can we at least explore the idea of fixing things that are broken to work with 3.82 first? My suggestion is to do the -exp run, then post here and to maintainers of broken ports directly and see what a reasonable time frame would be to get things fixed the right way first.

Preliminary runs show ~50 ports that break with 3.82, some of them unfortunately being dependencies for a reasonable number of others. An -exp has already been run, though there were a number of false positives for whatever reason.

There will absolutely _not_ be two gmake ports for anything more than a suitable deprecation period (if it is determined to move ahead) or for perhaps a month (specifically note that devel/gmake381 is marked IGNORE and not attached to the tree, so anyone trying to use it will have ... problems) if it's too much in the way of hacking.

> My understanding is that there is _currently_ no pressure to get gmake upgraded, so at least exploring the idea of doing it without a kludge seems reasonable to me, although I'm happy to be proven wrong.

The "kludge", in terms of actually testing things to get empirical data, rather than hand-waving about the sky falling, is ~4 lines of code in bsd.port.mk. We have a plan, we're going to get the results of that plan, and then do some analysis on it. Working closely with the pkgsrc tree that already _is_ at gmake-3.82

You may find a more productive approach would be to wander over to the gnumake mailing list, and ask why such a massive amount of backwards incompatibility was introduced in a minor version upgrade. Of course, that's entirely your prerogative. In the meantime, I along with a few others are actually going to _do_ the work involved in _testing_ the _possibility_ of this instead of sitting in our armchairs.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 12:05, Ade Lovett wrote:
>
> On Mar 10, 2011, at 13:24 , Doug Barton wrote:
>> Can you give us an idea of how many ports we're talking about?
>> Rather than having 2 gmake ports (which is likely to last for a
>> very long time, "best laid plans" aside) can we at least explore
>> the idea of fixing things that are broken to work with 3.82 first?
>> My suggestion is to do the -exp run, then post here and to
>> maintainers of broken ports directly and see what a reasonable time
>> frame would be to get things fixed the right way first.
>
> Preliminary runs show ~50 ports that break with 3.82, some of them
> unfortunately being dependencies for a reasonable number of others.
> An -exp has already been run, though there were a number of false
> positives for whatever reason.

What I'm suggesting is that the URL for the logs of that run get posted
here, along with contacting the maintainers of the affected ports. Then
let's see what people have to say about getting them fixed sooner rather
than later. Can you explain why doing that would be a bad idea?

> There will absolutely _not_ be two gmake ports for anything more than
> a suitable deprecation period

I admire your optimism, however experience tells us that once these
types of accomodations get into the tree, they stay there for a long time.

>> My understanding is that there is _currently_ no pressure to get
>> gmake upgraded, so at least exploring the idea of doing it without
>> a kludge seems reasonable to me, although I'm happy to be proven
>> wrong.
>
> The "kludge", in terms of actually testing things to get empirical
> data, rather than hand-waving about the sky falling,

Um, no one said the sky is falling, and you've reacted emotionally to
the term "kludge" rather than answering my question about what the
urgency is to get the update done.

> We have a plan, we're going to get the results
> of that plan, and then do some analysis on it.

And my concern is that the plan seems to have been formulated without
wider input from the community. So I ask again ... what harm can come
from at least trying to fix the broken ports first?


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 14:21 , Doug Barton wrote:
> What I'm suggesting is that the URL for the logs of that run get posted here, along with contacting the maintainers of the affected ports. Then let's see what people have to say about getting them fixed sooner rather than later. Can you explain why doing that would be a bad idea?

Those 50 or so ports are not the complete picture. Some of them are preventing other ports from being built. So, we cycle through an -exp run adding USE_GMAKE=381 (it's not a library or anything, just an executable, and in the context of clean building, only one or the other will exist for a specific port -exp build, so there's no question of interaction) until we have _all_ of the affected ports.

Then the list gets posted somewhere, USE_GMAKE=381 goes active, then there's a period (6-7 months) for folks to clean things up, at which point USE_GMAKE=381 does exactly the same as USE_GMAKE=yes (use gmake-3.82) -- ports that get fixed after this date simply change USE_GMAKE=381 -> USE_GMAKE=yes (cosmetic change only), and a list of known-broken ports can still be determined by grepping for 'USE_GMAKE=381'. If updates to those ports fix them, change USE_GMAKE back to 'yes'.

> I admire your optimism, however experience tells us that once these types of accomodations get into the tree, they stay there for a long time.

There is no issue of optimism about it. gmake-3.82 _will_ be the sole version of GNU make in the tree by (at latest) the end of this year.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 12:52, Ade Lovett wrote:
>
> On Mar 10, 2011, at 14:21 , Doug Barton wrote:
>> What I'm suggesting is that the URL for the logs of that run get
>> posted here, along with contacting the maintainers of the affected
>> ports. Then let's see what people have to say about getting them
>> fixed sooner rather than later. Can you explain why doing that
>> would be a bad idea?
>
> Those 50 or so ports are not the complete picture. Some of them are
> preventing other ports from being built. So, we cycle through an
> -exp run adding USE_GMAKE=381 (it's not a library or anything, just
> an executable, and in the context of clean building, only one or the
> other will exist for a specific port -exp build, so there's no
> question of interaction) until we have _all_ of the affected ports.
>
> Then the list gets posted somewhere,

Great!

> USE_GMAKE=381 goes active,

That's the bit that we disagree on, but your unwillingness to answer the
question I've posed twice now tells me clearly that you are determined
to follow this course of action, so I give up.

>> I admire your optimism, however experience tells us that once these
>> types of accomodations get into the tree, they stay there for a
>> long time.
>
> There is no issue of optimism about it. gmake-3.82 _will_ be the
> sole version of GNU make in the tree by (at latest) the end of this
> year.

You've already slipped your deadline from 6 months firm, to 6-7 months,
now to 9 months in the course of just a few emails. I'd be willing to
wager $BEVERAGE of your choice that we enter 2012 with multiple gmakes
in the ports tree. But like I said, I'd be glad to be proven wrong. :)


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On Thu, Mar 10, 2011 at 02:05:50PM -0600, Ade Lovett wrote:
> Preliminary runs show ~50 ports that break with 3.82, some of them
> unfortunately being dependencies for a reasonable number of others.

For values of "reasonable" in the ~1100 range.

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On Mar 10, 2011, at 14:21 , Doug Barton wrote:
> I admire your optimism, however experience tells us that once these
> types of accomodations get into the tree, they stay there for a long
> time.

Here's what I have on my system:

devel/autoconf
devel/autoconf213
devel/automake
devel/automake14
devel/autotools
devel/libtool

(That's not counting the -wrapper convenience ports.)

So: one antiquated version each of autoconf and automake.

$ dependson autoconf-2.1 | wc -l
73
$ dependson autoconf | wc -l
910
$ dependson automake-1.4 | wc -l
31
$ dependson automake | wc -l
325

('dependson' is just a script that greps INDEX.)

Summary: there used to be a lot of auto* ports. There aren't, now.

Anyone interested in looking through the sordid details can find them at
http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/ .

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

Mark Linimon writes:

> Summary: there used to be a lot of auto* ports. There aren't,
> now.

Am I correct in remembering the "used to be" period covered
2+(+) years?


Robert "sure seemed like it :-)" Huff


_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 15:54, Mark Linimon wrote:
> On Mar 10, 2011, at 14:21 , Doug Barton wrote:
>> I admire your optimism, however experience tells us that once these
>> types of accomodations get into the tree, they stay there for a long
>> time.
>
> Here's what I have on my system:
>
> devel/autoconf
> devel/autoconf213
> devel/automake
> devel/automake14
> devel/autotools
> devel/libtool
>
> (That's not counting the -wrapper convenience ports.)

[snip]

> Summary: there used to be a lot of auto* ports. There aren't, now.

First, my point was not "there are going to be a lot of gmake ports," my
point was, "there will be >1 for a long time after it's split into >1."
You have now proved my point, thanks. While we're discussing anecdotal
evidence:

autoconf-2.13.000227_6
autoconf-2.68

automake-1.4.6_6
automake-1.11.1

But that's only because I periodically do 'pkg_delete auto*' so this is
not really representative.

Meanwhile, this is why I reacted so strongly on IRC when it was
suggested that bifurcating gmake was the way to go. I was 100% certain
at the time that it was a foregone conclusion.

So maybe you will take a stab at my real question, what is the urgency
in upgrading gmake that prevents "fix the broken ports first" as an
option to at least explore? And while we're at it, if you have already
done the iterative -exp runs to get the 1100 ports figure, where are
those logs?


Thanks,

Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 18:09 , Doug Barton wrote:
> First, my point was not "there are going to be a lot of gmake ports," my point was, "there will be >1 for a long time after it's split into >1." You have now proved my point, thanks.

Apples and oranges, my friend. Given the sheer amount of stuff we have in ports/, there is a small amount of stuff that hasn't been updated in forever, nor ever will be, requiring the "legacy" autoconf-2.13/automake-1.4

Go look up pkgsrc. Or any Linux distribution. You'll find both of them lying there. I'd love to nuke them, and those ports that require them to build, but people tend to get upset when Really Important Application (sic) gets removed from under them.

As for the rest of your post. It's the usual diatribe. If you think you can do better, by all means, step up to the plate and actually _do_ something. Like yours truly has done reducing libtool to 1 version, and autoconf/automake to 2 versions (legacy and current).

Unless you're prepared to step up to the plate, offer alternate _concrete_ plans (as I have already done) and are willing to spend considerable brain and cpu cycles to get to the desired solution, you have no right to question what _is_ being done by those that _are_ doing it.

This is _not_ a democracy. The war cry of "Patches Welcome" should be obvious in that fact.

So. Let's see your patches. Seriously. Hell, if someone else takes this on (and note, it is only a matter of time before something fundamental _requires_ GNU make 3.82, so we can't just bury our heads in the sand), go for it.

Didn't think so.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 19:46, Ade Lovett wrote:
>
> On Mar 10, 2011, at 18:09 , Doug Barton wrote:
>> First, my point was not "there are going to be a lot of gmake
>> ports," my point was, "there will be>1 for a long time after it's
>> split into>1." You have now proved my point, thanks.
>
> Apples and oranges, my friend. Given the sheer amount of stuff we
> have in ports/, there is a small amount of stuff that hasn't been
> updated in forever, nor ever will be, requiring the "legacy"
> autoconf-2.13/automake-1.4

And my concern is that we're heading down the same road with gmake.
Maybe it's worth doing that, I don't know. It's hard to make an
intelligent decision when neither you nor Mark will answer what I think
is a totally reasonable question:

What is the urgency in upgrading gmake that prevents "fix the broken
ports first" as an option to at least explore?

> As for the rest of your post. It's the usual diatribe. If you think
> you can do better, by all means, step up to the plate and actually
> _do_ something.

Um, I do quite a bit, thanks. But even if I didn't, it doesn't mean that
I don't get to ask questions.

> Like yours truly has done reducing libtool to 1
> version, and autoconf/automake to 2 versions (legacy and current).

Yes, and that work has been greatly appreciated.

> Unless you're prepared to step up to the plate, offer alternate
> _concrete_ plans (as I have already done) and are willing to spend
> considerable brain and cpu cycles to get to the desired solution, you
> have no right to question what _is_ being done by those that _are_
> doing it.

Yeah, no ... that's not how this works. This is a community, with all
the problems that entails. Work on something this important should not
be happening in a vacuum. At bare minimum it's impossible to provide an
intelligent answer to the question of, "Is there a better way to do it?"
because we (the community) don't have all the facts. So what I'm asking
for as step 1 is, share the facts. Then step 2 _should be_, work
together to find the right solution. If it turns out that your idea is
actually the best one, then great, let's do it! OTOH, throwing the door
open and having the many smart people who are interested in making
FreeBSD ports better have a crack at it might just result in a
better/easier solution. It might even result in getting more volunteers
who have the desire and ability to actually help with the work. I don't
see a downside here. But if you'd like to engage in a discussion rather
than throwing around ad hominem's and pointless "patches welcome"
statements, maybe you can show me why I'm wrong.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

Work is now underway to bring GNU make 3.82 into the tree. Sadly, there are a number of rather unfortunate backwards incompatibility issues between this and 3.81 which makes a simple replacement unworkable.

A new port, devel/gmake381 has just been committed to the tree which is a heavily stripped down 3.81 version (just the binary, installed as ${LOCALBASE}/bin/gmake381, no NLS support. It is also currently marked IGNORE and is NOT attached to devel/Makefile. Please do NOT use it directly in any way, shape or form.

The next steps are as follows:

1. A patchset will be implemented, upgrading devel/gmake to 3.82, attaching devel/gmake381 to the build, and extending the USE_GMAKE variable so that a value of 'yes' will continue to use devel/gmake (now 3.82) and '381' will use the older 3.81

2. -exp runs will be iterated over to determine which ports break building with 3.82, and they will be marked as USE_GMAKE=381 to allow them to continue to build. A list of such ports will be maintained and posted.

3. devel/gmake381 will then be marked DEPRECATED with a suitable EXPIRATION_DATE (at least 6 months), at which point it will be removed, and the USE_GMAKE=381 logic also reverted, so that everything will go back to using devel/gmake. Note: it will not be necessary to edit individual port Makefiles back to USE_GMAKE=yes, since the checks for USE_GMAKE only look to see if the variable is defined. This will provide for ease of use (grep -R USE_GMAKE=381 ports/) to pick up any stragglers -- not to mention the fact that they'll most likely be broken in weird and interesting ways.

A followup posting will occur as and when steps (1) and (2) have been completed.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 09:43, Ade Lovett wrote:
> Work is now underway to bring GNU make 3.82 into the tree. Sadly,
> there are a number of rather unfortunate backwards incompatibility
> issues between this and 3.81 which makes a simple replacement
> unworkable.

Can you give us an idea of how many ports we're talking about? Rather
than having 2 gmake ports (which is likely to last for a very long time,
"best laid plans" aside) can we at least explore the idea of fixing
things that are broken to work with 3.82 first? My suggestion is to do
the -exp run, then post here and to maintainers of broken ports directly
and see what a reasonable time frame would be to get things fixed the
right way first.

My understanding is that there is _currently_ no pressure to get gmake
upgraded, so at least exploring the idea of doing it without a kludge
seems reasonable to me, although I'm happy to be proven wrong.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 13:24 , Doug Barton wrote:
> Can you give us an idea of how many ports we're talking about? Rather than having 2 gmake ports (which is likely to last for a very long time, "best laid plans" aside) can we at least explore the idea of fixing things that are broken to work with 3.82 first? My suggestion is to do the -exp run, then post here and to maintainers of broken ports directly and see what a reasonable time frame would be to get things fixed the right way first.

Preliminary runs show ~50 ports that break with 3.82, some of them unfortunately being dependencies for a reasonable number of others. An -exp has already been run, though there were a number of false positives for whatever reason.

There will absolutely _not_ be two gmake ports for anything more than a suitable deprecation period (if it is determined to move ahead) or for perhaps a month (specifically note that devel/gmake381 is marked IGNORE and not attached to the tree, so anyone trying to use it will have ... problems) if it's too much in the way of hacking.

> My understanding is that there is _currently_ no pressure to get gmake upgraded, so at least exploring the idea of doing it without a kludge seems reasonable to me, although I'm happy to be proven wrong.

The "kludge", in terms of actually testing things to get empirical data, rather than hand-waving about the sky falling, is ~4 lines of code in bsd.port.mk. We have a plan, we're going to get the results of that plan, and then do some analysis on it. Working closely with the pkgsrc tree that already _is_ at gmake-3.82

You may find a more productive approach would be to wander over to the gnumake mailing list, and ask why such a massive amount of backwards incompatibility was introduced in a minor version upgrade. Of course, that's entirely your prerogative. In the meantime, I along with a few others are actually going to _do_ the work involved in _testing_ the _possibility_ of this instead of sitting in our armchairs.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 12:05, Ade Lovett wrote:
>
> On Mar 10, 2011, at 13:24 , Doug Barton wrote:
>> Can you give us an idea of how many ports we're talking about?
>> Rather than having 2 gmake ports (which is likely to last for a
>> very long time, "best laid plans" aside) can we at least explore
>> the idea of fixing things that are broken to work with 3.82 first?
>> My suggestion is to do the -exp run, then post here and to
>> maintainers of broken ports directly and see what a reasonable time
>> frame would be to get things fixed the right way first.
>
> Preliminary runs show ~50 ports that break with 3.82, some of them
> unfortunately being dependencies for a reasonable number of others.
> An -exp has already been run, though there were a number of false
> positives for whatever reason.

What I'm suggesting is that the URL for the logs of that run get posted
here, along with contacting the maintainers of the affected ports. Then
let's see what people have to say about getting them fixed sooner rather
than later. Can you explain why doing that would be a bad idea?

> There will absolutely _not_ be two gmake ports for anything more than
> a suitable deprecation period

I admire your optimism, however experience tells us that once these
types of accomodations get into the tree, they stay there for a long time.

>> My understanding is that there is _currently_ no pressure to get
>> gmake upgraded, so at least exploring the idea of doing it without
>> a kludge seems reasonable to me, although I'm happy to be proven
>> wrong.
>
> The "kludge", in terms of actually testing things to get empirical
> data, rather than hand-waving about the sky falling,

Um, no one said the sky is falling, and you've reacted emotionally to
the term "kludge" rather than answering my question about what the
urgency is to get the update done.

> We have a plan, we're going to get the results
> of that plan, and then do some analysis on it.

And my concern is that the plan seems to have been formulated without
wider input from the community. So I ask again ... what harm can come
from at least trying to fix the broken ports first?


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 14:21 , Doug Barton wrote:
> What I'm suggesting is that the URL for the logs of that run get posted here, along with contacting the maintainers of the affected ports. Then let's see what people have to say about getting them fixed sooner rather than later. Can you explain why doing that would be a bad idea?

Those 50 or so ports are not the complete picture. Some of them are preventing other ports from being built. So, we cycle through an -exp run adding USE_GMAKE=381 (it's not a library or anything, just an executable, and in the context of clean building, only one or the other will exist for a specific port -exp build, so there's no question of interaction) until we have _all_ of the affected ports.

Then the list gets posted somewhere, USE_GMAKE=381 goes active, then there's a period (6-7 months) for folks to clean things up, at which point USE_GMAKE=381 does exactly the same as USE_GMAKE=yes (use gmake-3.82) -- ports that get fixed after this date simply change USE_GMAKE=381 -> USE_GMAKE=yes (cosmetic change only), and a list of known-broken ports can still be determined by grepping for 'USE_GMAKE=381'. If updates to those ports fix them, change USE_GMAKE back to 'yes'.

> I admire your optimism, however experience tells us that once these types of accomodations get into the tree, they stay there for a long time.

There is no issue of optimism about it. gmake-3.82 _will_ be the sole version of GNU make in the tree by (at latest) the end of this year.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 12:52, Ade Lovett wrote:
>
> On Mar 10, 2011, at 14:21 , Doug Barton wrote:
>> What I'm suggesting is that the URL for the logs of that run get
>> posted here, along with contacting the maintainers of the affected
>> ports. Then let's see what people have to say about getting them
>> fixed sooner rather than later. Can you explain why doing that
>> would be a bad idea?
>
> Those 50 or so ports are not the complete picture. Some of them are
> preventing other ports from being built. So, we cycle through an
> -exp run adding USE_GMAKE=381 (it's not a library or anything, just
> an executable, and in the context of clean building, only one or the
> other will exist for a specific port -exp build, so there's no
> question of interaction) until we have _all_ of the affected ports.
>
> Then the list gets posted somewhere,

Great!

> USE_GMAKE=381 goes active,

That's the bit that we disagree on, but your unwillingness to answer the
question I've posed twice now tells me clearly that you are determined
to follow this course of action, so I give up.

>> I admire your optimism, however experience tells us that once these
>> types of accomodations get into the tree, they stay there for a
>> long time.
>
> There is no issue of optimism about it. gmake-3.82 _will_ be the
> sole version of GNU make in the tree by (at latest) the end of this
> year.

You've already slipped your deadline from 6 months firm, to 6-7 months,
now to 9 months in the course of just a few emails. I'd be willing to
wager $BEVERAGE of your choice that we enter 2012 with multiple gmakes
in the ports tree. But like I said, I'd be glad to be proven wrong. :)


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On Thu, Mar 10, 2011 at 02:05:50PM -0600, Ade Lovett wrote:
> Preliminary runs show ~50 ports that break with 3.82, some of them
> unfortunately being dependencies for a reasonable number of others.

For values of "reasonable" in the ~1100 range.

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On Mar 10, 2011, at 14:21 , Doug Barton wrote:
> I admire your optimism, however experience tells us that once these
> types of accomodations get into the tree, they stay there for a long
> time.

Here's what I have on my system:

devel/autoconf
devel/autoconf213
devel/automake
devel/automake14
devel/autotools
devel/libtool

(That's not counting the -wrapper convenience ports.)

So: one antiquated version each of autoconf and automake.

$ dependson autoconf-2.1 | wc -l
73
$ dependson autoconf | wc -l
910
$ dependson automake-1.4 | wc -l
31
$ dependson automake | wc -l
325

('dependson' is just a script that greps INDEX.)

Summary: there used to be a lot of auto* ports. There aren't, now.

Anyone interested in looking through the sordid details can find them at
http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/ .

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

Mark Linimon writes:

> Summary: there used to be a lot of auto* ports. There aren't,
> now.

Am I correct in remembering the "used to be" period covered
2+(+) years?


Robert "sure seemed like it :-)" Huff


_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 15:54, Mark Linimon wrote:
> On Mar 10, 2011, at 14:21 , Doug Barton wrote:
>> I admire your optimism, however experience tells us that once these
>> types of accomodations get into the tree, they stay there for a long
>> time.
>
> Here's what I have on my system:
>
> devel/autoconf
> devel/autoconf213
> devel/automake
> devel/automake14
> devel/autotools
> devel/libtool
>
> (That's not counting the -wrapper convenience ports.)

[snip]

> Summary: there used to be a lot of auto* ports. There aren't, now.

First, my point was not "there are going to be a lot of gmake ports," my
point was, "there will be >1 for a long time after it's split into >1."
You have now proved my point, thanks. While we're discussing anecdotal
evidence:

autoconf-2.13.000227_6
autoconf-2.68

automake-1.4.6_6
automake-1.11.1

But that's only because I periodically do 'pkg_delete auto*' so this is
not really representative.

Meanwhile, this is why I reacted so strongly on IRC when it was
suggested that bifurcating gmake was the way to go. I was 100% certain
at the time that it was a foregone conclusion.

So maybe you will take a stab at my real question, what is the urgency
in upgrading gmake that prevents "fix the broken ports first" as an
option to at least explore? And while we're at it, if you have already
done the iterative -exp runs to get the 1100 ports figure, where are
those logs?


Thanks,

Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 18:09 , Doug Barton wrote:
> First, my point was not "there are going to be a lot of gmake ports," my point was, "there will be >1 for a long time after it's split into >1." You have now proved my point, thanks.

Apples and oranges, my friend. Given the sheer amount of stuff we have in ports/, there is a small amount of stuff that hasn't been updated in forever, nor ever will be, requiring the "legacy" autoconf-2.13/automake-1.4

Go look up pkgsrc. Or any Linux distribution. You'll find both of them lying there. I'd love to nuke them, and those ports that require them to build, but people tend to get upset when Really Important Application (sic) gets removed from under them.

As for the rest of your post. It's the usual diatribe. If you think you can do better, by all means, step up to the plate and actually _do_ something. Like yours truly has done reducing libtool to 1 version, and autoconf/automake to 2 versions (legacy and current).

Unless you're prepared to step up to the plate, offer alternate _concrete_ plans (as I have already done) and are willing to spend considerable brain and cpu cycles to get to the desired solution, you have no right to question what _is_ being done by those that _are_ doing it.

This is _not_ a democracy. The war cry of "Patches Welcome" should be obvious in that fact.

So. Let's see your patches. Seriously. Hell, if someone else takes this on (and note, it is only a matter of time before something fundamental _requires_ GNU make 3.82, so we can't just bury our heads in the sand), go for it.

Didn't think so.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 19:46, Ade Lovett wrote:
>
> On Mar 10, 2011, at 18:09 , Doug Barton wrote:
>> First, my point was not "there are going to be a lot of gmake
>> ports," my point was, "there will be>1 for a long time after it's
>> split into>1." You have now proved my point, thanks.
>
> Apples and oranges, my friend. Given the sheer amount of stuff we
> have in ports/, there is a small amount of stuff that hasn't been
> updated in forever, nor ever will be, requiring the "legacy"
> autoconf-2.13/automake-1.4

And my concern is that we're heading down the same road with gmake.
Maybe it's worth doing that, I don't know. It's hard to make an
intelligent decision when neither you nor Mark will answer what I think
is a totally reasonable question:

What is the urgency in upgrading gmake that prevents "fix the broken
ports first" as an option to at least explore?

> As for the rest of your post. It's the usual diatribe. If you think
> you can do better, by all means, step up to the plate and actually
> _do_ something.

Um, I do quite a bit, thanks. But even if I didn't, it doesn't mean that
I don't get to ask questions.

> Like yours truly has done reducing libtool to 1
> version, and autoconf/automake to 2 versions (legacy and current).

Yes, and that work has been greatly appreciated.

> Unless you're prepared to step up to the plate, offer alternate
> _concrete_ plans (as I have already done) and are willing to spend
> considerable brain and cpu cycles to get to the desired solution, you
> have no right to question what _is_ being done by those that _are_
> doing it.

Yeah, no ... that's not how this works. This is a community, with all
the problems that entails. Work on something this important should not
be happening in a vacuum. At bare minimum it's impossible to provide an
intelligent answer to the question of, "Is there a better way to do it?"
because we (the community) don't have all the facts. So what I'm asking
for as step 1 is, share the facts. Then step 2 _should be_, work
together to find the right solution. If it turns out that your idea is
actually the best one, then great, let's do it! OTOH, throwing the door
open and having the many smart people who are interested in making
FreeBSD ports better have a crack at it might just result in a
better/easier solution. It might even result in getting more volunteers
who have the desire and ability to actually help with the work. I don't
see a downside here. But if you'd like to engage in a discussion rather
than throwing around ad hominem's and pointless "patches welcome"
statements, maybe you can show me why I'm wrong.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
I answered this question last night on IRC, aDe answered it in email:

> What is the urgency in upgrading gmake that prevents "fix the broken
> ports first" as an option to at least explore?

Now that gmake is out, if the past is any indication, some project
will quickly upgrade to it. We can wait for that to happen, and then
have to scramble, or we can get ahead of the curve.

Not every single change to the Ports Collection rises to the level of
requiring a committee meeting to generate a consensus. IMHO this does
not. In this case it was "here is someone willing to do the work, here's
an action plan, let's just do it."

I've already spent nearly as much time arguing with you as I had spent
running the initial -exp run (more, if you exclude the work I did to
update the processonelog script), so I'm done here.

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

Work is now underway to bring GNU make 3.82 into the tree. Sadly, there are a number of rather unfortunate backwards incompatibility issues between this and 3.81 which makes a simple replacement unworkable.

A new port, devel/gmake381 has just been committed to the tree which is a heavily stripped down 3.81 version (just the binary, installed as ${LOCALBASE}/bin/gmake381, no NLS support. It is also currently marked IGNORE and is NOT attached to devel/Makefile. Please do NOT use it directly in any way, shape or form.

The next steps are as follows:

1. A patchset will be implemented, upgrading devel/gmake to 3.82, attaching devel/gmake381 to the build, and extending the USE_GMAKE variable so that a value of 'yes' will continue to use devel/gmake (now 3.82) and '381' will use the older 3.81

2. -exp runs will be iterated over to determine which ports break building with 3.82, and they will be marked as USE_GMAKE=381 to allow them to continue to build. A list of such ports will be maintained and posted.

3. devel/gmake381 will then be marked DEPRECATED with a suitable EXPIRATION_DATE (at least 6 months), at which point it will be removed, and the USE_GMAKE=381 logic also reverted, so that everything will go back to using devel/gmake. Note: it will not be necessary to edit individual port Makefiles back to USE_GMAKE=yes, since the checks for USE_GMAKE only look to see if the variable is defined. This will provide for ease of use (grep -R USE_GMAKE=381 ports/) to pick up any stragglers -- not to mention the fact that they'll most likely be broken in weird and interesting ways.

A followup posting will occur as and when steps (1) and (2) have been completed.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 09:43, Ade Lovett wrote:
> Work is now underway to bring GNU make 3.82 into the tree. Sadly,
> there are a number of rather unfortunate backwards incompatibility
> issues between this and 3.81 which makes a simple replacement
> unworkable.

Can you give us an idea of how many ports we're talking about? Rather
than having 2 gmake ports (which is likely to last for a very long time,
"best laid plans" aside) can we at least explore the idea of fixing
things that are broken to work with 3.82 first? My suggestion is to do
the -exp run, then post here and to maintainers of broken ports directly
and see what a reasonable time frame would be to get things fixed the
right way first.

My understanding is that there is _currently_ no pressure to get gmake
upgraded, so at least exploring the idea of doing it without a kludge
seems reasonable to me, although I'm happy to be proven wrong.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 13:24 , Doug Barton wrote:
> Can you give us an idea of how many ports we're talking about? Rather than having 2 gmake ports (which is likely to last for a very long time, "best laid plans" aside) can we at least explore the idea of fixing things that are broken to work with 3.82 first? My suggestion is to do the -exp run, then post here and to maintainers of broken ports directly and see what a reasonable time frame would be to get things fixed the right way first.

Preliminary runs show ~50 ports that break with 3.82, some of them unfortunately being dependencies for a reasonable number of others. An -exp has already been run, though there were a number of false positives for whatever reason.

There will absolutely _not_ be two gmake ports for anything more than a suitable deprecation period (if it is determined to move ahead) or for perhaps a month (specifically note that devel/gmake381 is marked IGNORE and not attached to the tree, so anyone trying to use it will have ... problems) if it's too much in the way of hacking.

> My understanding is that there is _currently_ no pressure to get gmake upgraded, so at least exploring the idea of doing it without a kludge seems reasonable to me, although I'm happy to be proven wrong.

The "kludge", in terms of actually testing things to get empirical data, rather than hand-waving about the sky falling, is ~4 lines of code in bsd.port.mk. We have a plan, we're going to get the results of that plan, and then do some analysis on it. Working closely with the pkgsrc tree that already _is_ at gmake-3.82

You may find a more productive approach would be to wander over to the gnumake mailing list, and ask why such a massive amount of backwards incompatibility was introduced in a minor version upgrade. Of course, that's entirely your prerogative. In the meantime, I along with a few others are actually going to _do_ the work involved in _testing_ the _possibility_ of this instead of sitting in our armchairs.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 12:05, Ade Lovett wrote:
>
> On Mar 10, 2011, at 13:24 , Doug Barton wrote:
>> Can you give us an idea of how many ports we're talking about?
>> Rather than having 2 gmake ports (which is likely to last for a
>> very long time, "best laid plans" aside) can we at least explore
>> the idea of fixing things that are broken to work with 3.82 first?
>> My suggestion is to do the -exp run, then post here and to
>> maintainers of broken ports directly and see what a reasonable time
>> frame would be to get things fixed the right way first.
>
> Preliminary runs show ~50 ports that break with 3.82, some of them
> unfortunately being dependencies for a reasonable number of others.
> An -exp has already been run, though there were a number of false
> positives for whatever reason.

What I'm suggesting is that the URL for the logs of that run get posted
here, along with contacting the maintainers of the affected ports. Then
let's see what people have to say about getting them fixed sooner rather
than later. Can you explain why doing that would be a bad idea?

> There will absolutely _not_ be two gmake ports for anything more than
> a suitable deprecation period

I admire your optimism, however experience tells us that once these
types of accomodations get into the tree, they stay there for a long time.

>> My understanding is that there is _currently_ no pressure to get
>> gmake upgraded, so at least exploring the idea of doing it without
>> a kludge seems reasonable to me, although I'm happy to be proven
>> wrong.
>
> The "kludge", in terms of actually testing things to get empirical
> data, rather than hand-waving about the sky falling,

Um, no one said the sky is falling, and you've reacted emotionally to
the term "kludge" rather than answering my question about what the
urgency is to get the update done.

> We have a plan, we're going to get the results
> of that plan, and then do some analysis on it.

And my concern is that the plan seems to have been formulated without
wider input from the community. So I ask again ... what harm can come
from at least trying to fix the broken ports first?


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 14:21 , Doug Barton wrote:
> What I'm suggesting is that the URL for the logs of that run get posted here, along with contacting the maintainers of the affected ports. Then let's see what people have to say about getting them fixed sooner rather than later. Can you explain why doing that would be a bad idea?

Those 50 or so ports are not the complete picture. Some of them are preventing other ports from being built. So, we cycle through an -exp run adding USE_GMAKE=381 (it's not a library or anything, just an executable, and in the context of clean building, only one or the other will exist for a specific port -exp build, so there's no question of interaction) until we have _all_ of the affected ports.

Then the list gets posted somewhere, USE_GMAKE=381 goes active, then there's a period (6-7 months) for folks to clean things up, at which point USE_GMAKE=381 does exactly the same as USE_GMAKE=yes (use gmake-3.82) -- ports that get fixed after this date simply change USE_GMAKE=381 -> USE_GMAKE=yes (cosmetic change only), and a list of known-broken ports can still be determined by grepping for 'USE_GMAKE=381'. If updates to those ports fix them, change USE_GMAKE back to 'yes'.

> I admire your optimism, however experience tells us that once these types of accomodations get into the tree, they stay there for a long time.

There is no issue of optimism about it. gmake-3.82 _will_ be the sole version of GNU make in the tree by (at latest) the end of this year.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 12:52, Ade Lovett wrote:
>
> On Mar 10, 2011, at 14:21 , Doug Barton wrote:
>> What I'm suggesting is that the URL for the logs of that run get
>> posted here, along with contacting the maintainers of the affected
>> ports. Then let's see what people have to say about getting them
>> fixed sooner rather than later. Can you explain why doing that
>> would be a bad idea?
>
> Those 50 or so ports are not the complete picture. Some of them are
> preventing other ports from being built. So, we cycle through an
> -exp run adding USE_GMAKE=381 (it's not a library or anything, just
> an executable, and in the context of clean building, only one or the
> other will exist for a specific port -exp build, so there's no
> question of interaction) until we have _all_ of the affected ports.
>
> Then the list gets posted somewhere,

Great!

> USE_GMAKE=381 goes active,

That's the bit that we disagree on, but your unwillingness to answer the
question I've posed twice now tells me clearly that you are determined
to follow this course of action, so I give up.

>> I admire your optimism, however experience tells us that once these
>> types of accomodations get into the tree, they stay there for a
>> long time.
>
> There is no issue of optimism about it. gmake-3.82 _will_ be the
> sole version of GNU make in the tree by (at latest) the end of this
> year.

You've already slipped your deadline from 6 months firm, to 6-7 months,
now to 9 months in the course of just a few emails. I'd be willing to
wager $BEVERAGE of your choice that we enter 2012 with multiple gmakes
in the ports tree. But like I said, I'd be glad to be proven wrong. :)


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On Thu, Mar 10, 2011 at 02:05:50PM -0600, Ade Lovett wrote:
> Preliminary runs show ~50 ports that break with 3.82, some of them
> unfortunately being dependencies for a reasonable number of others.

For values of "reasonable" in the ~1100 range.

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On Mar 10, 2011, at 14:21 , Doug Barton wrote:
> I admire your optimism, however experience tells us that once these
> types of accomodations get into the tree, they stay there for a long
> time.

Here's what I have on my system:

devel/autoconf
devel/autoconf213
devel/automake
devel/automake14
devel/autotools
devel/libtool

(That's not counting the -wrapper convenience ports.)

So: one antiquated version each of autoconf and automake.

$ dependson autoconf-2.1 | wc -l
73
$ dependson autoconf | wc -l
910
$ dependson automake-1.4 | wc -l
31
$ dependson automake | wc -l
325

('dependson' is just a script that greps INDEX.)

Summary: there used to be a lot of auto* ports. There aren't, now.

Anyone interested in looking through the sordid details can find them at
http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/ .

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

Mark Linimon writes:

> Summary: there used to be a lot of auto* ports. There aren't,
> now.

Am I correct in remembering the "used to be" period covered
2+(+) years?


Robert "sure seemed like it :-)" Huff


_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 15:54, Mark Linimon wrote:
> On Mar 10, 2011, at 14:21 , Doug Barton wrote:
>> I admire your optimism, however experience tells us that once these
>> types of accomodations get into the tree, they stay there for a long
>> time.
>
> Here's what I have on my system:
>
> devel/autoconf
> devel/autoconf213
> devel/automake
> devel/automake14
> devel/autotools
> devel/libtool
>
> (That's not counting the -wrapper convenience ports.)

[snip]

> Summary: there used to be a lot of auto* ports. There aren't, now.

First, my point was not "there are going to be a lot of gmake ports," my
point was, "there will be >1 for a long time after it's split into >1."
You have now proved my point, thanks. While we're discussing anecdotal
evidence:

autoconf-2.13.000227_6
autoconf-2.68

automake-1.4.6_6
automake-1.11.1

But that's only because I periodically do 'pkg_delete auto*' so this is
not really representative.

Meanwhile, this is why I reacted so strongly on IRC when it was
suggested that bifurcating gmake was the way to go. I was 100% certain
at the time that it was a foregone conclusion.

So maybe you will take a stab at my real question, what is the urgency
in upgrading gmake that prevents "fix the broken ports first" as an
option to at least explore? And while we're at it, if you have already
done the iterative -exp runs to get the 1100 ports figure, where are
those logs?


Thanks,

Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 18:09 , Doug Barton wrote:
> First, my point was not "there are going to be a lot of gmake ports," my point was, "there will be >1 for a long time after it's split into >1." You have now proved my point, thanks.

Apples and oranges, my friend. Given the sheer amount of stuff we have in ports/, there is a small amount of stuff that hasn't been updated in forever, nor ever will be, requiring the "legacy" autoconf-2.13/automake-1.4

Go look up pkgsrc. Or any Linux distribution. You'll find both of them lying there. I'd love to nuke them, and those ports that require them to build, but people tend to get upset when Really Important Application (sic) gets removed from under them.

As for the rest of your post. It's the usual diatribe. If you think you can do better, by all means, step up to the plate and actually _do_ something. Like yours truly has done reducing libtool to 1 version, and autoconf/automake to 2 versions (legacy and current).

Unless you're prepared to step up to the plate, offer alternate _concrete_ plans (as I have already done) and are willing to spend considerable brain and cpu cycles to get to the desired solution, you have no right to question what _is_ being done by those that _are_ doing it.

This is _not_ a democracy. The war cry of "Patches Welcome" should be obvious in that fact.

So. Let's see your patches. Seriously. Hell, if someone else takes this on (and note, it is only a matter of time before something fundamental _requires_ GNU make 3.82, so we can't just bury our heads in the sand), go for it.

Didn't think so.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 19:46, Ade Lovett wrote:
>
> On Mar 10, 2011, at 18:09 , Doug Barton wrote:
>> First, my point was not "there are going to be a lot of gmake
>> ports," my point was, "there will be>1 for a long time after it's
>> split into>1." You have now proved my point, thanks.
>
> Apples and oranges, my friend. Given the sheer amount of stuff we
> have in ports/, there is a small amount of stuff that hasn't been
> updated in forever, nor ever will be, requiring the "legacy"
> autoconf-2.13/automake-1.4

And my concern is that we're heading down the same road with gmake.
Maybe it's worth doing that, I don't know. It's hard to make an
intelligent decision when neither you nor Mark will answer what I think
is a totally reasonable question:

What is the urgency in upgrading gmake that prevents "fix the broken
ports first" as an option to at least explore?

> As for the rest of your post. It's the usual diatribe. If you think
> you can do better, by all means, step up to the plate and actually
> _do_ something.

Um, I do quite a bit, thanks. But even if I didn't, it doesn't mean that
I don't get to ask questions.

> Like yours truly has done reducing libtool to 1
> version, and autoconf/automake to 2 versions (legacy and current).

Yes, and that work has been greatly appreciated.

> Unless you're prepared to step up to the plate, offer alternate
> _concrete_ plans (as I have already done) and are willing to spend
> considerable brain and cpu cycles to get to the desired solution, you
> have no right to question what _is_ being done by those that _are_
> doing it.

Yeah, no ... that's not how this works. This is a community, with all
the problems that entails. Work on something this important should not
be happening in a vacuum. At bare minimum it's impossible to provide an
intelligent answer to the question of, "Is there a better way to do it?"
because we (the community) don't have all the facts. So what I'm asking
for as step 1 is, share the facts. Then step 2 _should be_, work
together to find the right solution. If it turns out that your idea is
actually the best one, then great, let's do it! OTOH, throwing the door
open and having the many smart people who are interested in making
FreeBSD ports better have a crack at it might just result in a
better/easier solution. It might even result in getting more volunteers
who have the desire and ability to actually help with the work. I don't
see a downside here. But if you'd like to engage in a discussion rather
than throwing around ad hominem's and pointless "patches welcome"
statements, maybe you can show me why I'm wrong.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
I answered this question last night on IRC, aDe answered it in email:

> What is the urgency in upgrading gmake that prevents "fix the broken
> ports first" as an option to at least explore?

Now that gmake is out, if the past is any indication, some project
will quickly upgrade to it. We can wait for that to happen, and then
have to scramble, or we can get ahead of the curve.

Not every single change to the Ports Collection rises to the level of
requiring a committee meeting to generate a consensus. IMHO this does
not. In this case it was "here is someone willing to do the work, here's
an action plan, let's just do it."

I've already spent nearly as much time arguing with you as I had spent
running the initial -exp run (more, if you exclude the work I did to
update the processonelog script), so I'm done here.

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 22:02 , Doug Barton wrote:
> But if you'd like to engage in a discussion rather than throwing around ad hominem's and pointless "patches welcome" statements, maybe you can show me why I'm wrong.

How about working from the basis that perhaps, just perhaps, I'm _right_, and show me why _I_ am wrong. After all, right now, I see me and a few others doing actual _work_, and others merely taking potshots.

By all means, show an alternate solution, one that assumes that some project or another, which will be a part of the FreeBSD ports collection, will _require_ GNU make 3.82, and we can go from there.

Believe me, I'm willing to listen to well thought on, start to end, include all possibility plans, but right now, all I'm seeing is "you're wrong" without anything substantial to back it up so, at this point, I'd like to focus on the issue at hand and get the work _done_.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

Work is now underway to bring GNU make 3.82 into the tree. Sadly, there are a number of rather unfortunate backwards incompatibility issues between this and 3.81 which makes a simple replacement unworkable.

A new port, devel/gmake381 has just been committed to the tree which is a heavily stripped down 3.81 version (just the binary, installed as ${LOCALBASE}/bin/gmake381, no NLS support. It is also currently marked IGNORE and is NOT attached to devel/Makefile. Please do NOT use it directly in any way, shape or form.

The next steps are as follows:

1. A patchset will be implemented, upgrading devel/gmake to 3.82, attaching devel/gmake381 to the build, and extending the USE_GMAKE variable so that a value of 'yes' will continue to use devel/gmake (now 3.82) and '381' will use the older 3.81

2. -exp runs will be iterated over to determine which ports break building with 3.82, and they will be marked as USE_GMAKE=381 to allow them to continue to build. A list of such ports will be maintained and posted.

3. devel/gmake381 will then be marked DEPRECATED with a suitable EXPIRATION_DATE (at least 6 months), at which point it will be removed, and the USE_GMAKE=381 logic also reverted, so that everything will go back to using devel/gmake. Note: it will not be necessary to edit individual port Makefiles back to USE_GMAKE=yes, since the checks for USE_GMAKE only look to see if the variable is defined. This will provide for ease of use (grep -R USE_GMAKE=381 ports/) to pick up any stragglers -- not to mention the fact that they'll most likely be broken in weird and interesting ways.

A followup posting will occur as and when steps (1) and (2) have been completed.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 09:43, Ade Lovett wrote:
> Work is now underway to bring GNU make 3.82 into the tree. Sadly,
> there are a number of rather unfortunate backwards incompatibility
> issues between this and 3.81 which makes a simple replacement
> unworkable.

Can you give us an idea of how many ports we're talking about? Rather
than having 2 gmake ports (which is likely to last for a very long time,
"best laid plans" aside) can we at least explore the idea of fixing
things that are broken to work with 3.82 first? My suggestion is to do
the -exp run, then post here and to maintainers of broken ports directly
and see what a reasonable time frame would be to get things fixed the
right way first.

My understanding is that there is _currently_ no pressure to get gmake
upgraded, so at least exploring the idea of doing it without a kludge
seems reasonable to me, although I'm happy to be proven wrong.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 13:24 , Doug Barton wrote:
> Can you give us an idea of how many ports we're talking about? Rather than having 2 gmake ports (which is likely to last for a very long time, "best laid plans" aside) can we at least explore the idea of fixing things that are broken to work with 3.82 first? My suggestion is to do the -exp run, then post here and to maintainers of broken ports directly and see what a reasonable time frame would be to get things fixed the right way first.

Preliminary runs show ~50 ports that break with 3.82, some of them unfortunately being dependencies for a reasonable number of others. An -exp has already been run, though there were a number of false positives for whatever reason.

There will absolutely _not_ be two gmake ports for anything more than a suitable deprecation period (if it is determined to move ahead) or for perhaps a month (specifically note that devel/gmake381 is marked IGNORE and not attached to the tree, so anyone trying to use it will have ... problems) if it's too much in the way of hacking.

> My understanding is that there is _currently_ no pressure to get gmake upgraded, so at least exploring the idea of doing it without a kludge seems reasonable to me, although I'm happy to be proven wrong.

The "kludge", in terms of actually testing things to get empirical data, rather than hand-waving about the sky falling, is ~4 lines of code in bsd.port.mk. We have a plan, we're going to get the results of that plan, and then do some analysis on it. Working closely with the pkgsrc tree that already _is_ at gmake-3.82

You may find a more productive approach would be to wander over to the gnumake mailing list, and ask why such a massive amount of backwards incompatibility was introduced in a minor version upgrade. Of course, that's entirely your prerogative. In the meantime, I along with a few others are actually going to _do_ the work involved in _testing_ the _possibility_ of this instead of sitting in our armchairs.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 12:05, Ade Lovett wrote:
>
> On Mar 10, 2011, at 13:24 , Doug Barton wrote:
>> Can you give us an idea of how many ports we're talking about?
>> Rather than having 2 gmake ports (which is likely to last for a
>> very long time, "best laid plans" aside) can we at least explore
>> the idea of fixing things that are broken to work with 3.82 first?
>> My suggestion is to do the -exp run, then post here and to
>> maintainers of broken ports directly and see what a reasonable time
>> frame would be to get things fixed the right way first.
>
> Preliminary runs show ~50 ports that break with 3.82, some of them
> unfortunately being dependencies for a reasonable number of others.
> An -exp has already been run, though there were a number of false
> positives for whatever reason.

What I'm suggesting is that the URL for the logs of that run get posted
here, along with contacting the maintainers of the affected ports. Then
let's see what people have to say about getting them fixed sooner rather
than later. Can you explain why doing that would be a bad idea?

> There will absolutely _not_ be two gmake ports for anything more than
> a suitable deprecation period

I admire your optimism, however experience tells us that once these
types of accomodations get into the tree, they stay there for a long time.

>> My understanding is that there is _currently_ no pressure to get
>> gmake upgraded, so at least exploring the idea of doing it without
>> a kludge seems reasonable to me, although I'm happy to be proven
>> wrong.
>
> The "kludge", in terms of actually testing things to get empirical
> data, rather than hand-waving about the sky falling,

Um, no one said the sky is falling, and you've reacted emotionally to
the term "kludge" rather than answering my question about what the
urgency is to get the update done.

> We have a plan, we're going to get the results
> of that plan, and then do some analysis on it.

And my concern is that the plan seems to have been formulated without
wider input from the community. So I ask again ... what harm can come
from at least trying to fix the broken ports first?


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 14:21 , Doug Barton wrote:
> What I'm suggesting is that the URL for the logs of that run get posted here, along with contacting the maintainers of the affected ports. Then let's see what people have to say about getting them fixed sooner rather than later. Can you explain why doing that would be a bad idea?

Those 50 or so ports are not the complete picture. Some of them are preventing other ports from being built. So, we cycle through an -exp run adding USE_GMAKE=381 (it's not a library or anything, just an executable, and in the context of clean building, only one or the other will exist for a specific port -exp build, so there's no question of interaction) until we have _all_ of the affected ports.

Then the list gets posted somewhere, USE_GMAKE=381 goes active, then there's a period (6-7 months) for folks to clean things up, at which point USE_GMAKE=381 does exactly the same as USE_GMAKE=yes (use gmake-3.82) -- ports that get fixed after this date simply change USE_GMAKE=381 -> USE_GMAKE=yes (cosmetic change only), and a list of known-broken ports can still be determined by grepping for 'USE_GMAKE=381'. If updates to those ports fix them, change USE_GMAKE back to 'yes'.

> I admire your optimism, however experience tells us that once these types of accomodations get into the tree, they stay there for a long time.

There is no issue of optimism about it. gmake-3.82 _will_ be the sole version of GNU make in the tree by (at latest) the end of this year.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 12:52, Ade Lovett wrote:
>
> On Mar 10, 2011, at 14:21 , Doug Barton wrote:
>> What I'm suggesting is that the URL for the logs of that run get
>> posted here, along with contacting the maintainers of the affected
>> ports. Then let's see what people have to say about getting them
>> fixed sooner rather than later. Can you explain why doing that
>> would be a bad idea?
>
> Those 50 or so ports are not the complete picture. Some of them are
> preventing other ports from being built. So, we cycle through an
> -exp run adding USE_GMAKE=381 (it's not a library or anything, just
> an executable, and in the context of clean building, only one or the
> other will exist for a specific port -exp build, so there's no
> question of interaction) until we have _all_ of the affected ports.
>
> Then the list gets posted somewhere,

Great!

> USE_GMAKE=381 goes active,

That's the bit that we disagree on, but your unwillingness to answer the
question I've posed twice now tells me clearly that you are determined
to follow this course of action, so I give up.

>> I admire your optimism, however experience tells us that once these
>> types of accomodations get into the tree, they stay there for a
>> long time.
>
> There is no issue of optimism about it. gmake-3.82 _will_ be the
> sole version of GNU make in the tree by (at latest) the end of this
> year.

You've already slipped your deadline from 6 months firm, to 6-7 months,
now to 9 months in the course of just a few emails. I'd be willing to
wager $BEVERAGE of your choice that we enter 2012 with multiple gmakes
in the ports tree. But like I said, I'd be glad to be proven wrong. :)


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On Thu, Mar 10, 2011 at 02:05:50PM -0600, Ade Lovett wrote:
> Preliminary runs show ~50 ports that break with 3.82, some of them
> unfortunately being dependencies for a reasonable number of others.

For values of "reasonable" in the ~1100 range.

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On Mar 10, 2011, at 14:21 , Doug Barton wrote:
> I admire your optimism, however experience tells us that once these
> types of accomodations get into the tree, they stay there for a long
> time.

Here's what I have on my system:

devel/autoconf
devel/autoconf213
devel/automake
devel/automake14
devel/autotools
devel/libtool

(That's not counting the -wrapper convenience ports.)

So: one antiquated version each of autoconf and automake.

$ dependson autoconf-2.1 | wc -l
73
$ dependson autoconf | wc -l
910
$ dependson automake-1.4 | wc -l
31
$ dependson automake | wc -l
325

('dependson' is just a script that greps INDEX.)

Summary: there used to be a lot of auto* ports. There aren't, now.

Anyone interested in looking through the sordid details can find them at
http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/ .

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

Mark Linimon writes:

> Summary: there used to be a lot of auto* ports. There aren't,
> now.

Am I correct in remembering the "used to be" period covered
2+(+) years?


Robert "sure seemed like it :-)" Huff


_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 15:54, Mark Linimon wrote:
> On Mar 10, 2011, at 14:21 , Doug Barton wrote:
>> I admire your optimism, however experience tells us that once these
>> types of accomodations get into the tree, they stay there for a long
>> time.
>
> Here's what I have on my system:
>
> devel/autoconf
> devel/autoconf213
> devel/automake
> devel/automake14
> devel/autotools
> devel/libtool
>
> (That's not counting the -wrapper convenience ports.)

[snip]

> Summary: there used to be a lot of auto* ports. There aren't, now.

First, my point was not "there are going to be a lot of gmake ports," my
point was, "there will be >1 for a long time after it's split into >1."
You have now proved my point, thanks. While we're discussing anecdotal
evidence:

autoconf-2.13.000227_6
autoconf-2.68

automake-1.4.6_6
automake-1.11.1

But that's only because I periodically do 'pkg_delete auto*' so this is
not really representative.

Meanwhile, this is why I reacted so strongly on IRC when it was
suggested that bifurcating gmake was the way to go. I was 100% certain
at the time that it was a foregone conclusion.

So maybe you will take a stab at my real question, what is the urgency
in upgrading gmake that prevents "fix the broken ports first" as an
option to at least explore? And while we're at it, if you have already
done the iterative -exp runs to get the 1100 ports figure, where are
those logs?


Thanks,

Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 18:09 , Doug Barton wrote:
> First, my point was not "there are going to be a lot of gmake ports," my point was, "there will be >1 for a long time after it's split into >1." You have now proved my point, thanks.

Apples and oranges, my friend. Given the sheer amount of stuff we have in ports/, there is a small amount of stuff that hasn't been updated in forever, nor ever will be, requiring the "legacy" autoconf-2.13/automake-1.4

Go look up pkgsrc. Or any Linux distribution. You'll find both of them lying there. I'd love to nuke them, and those ports that require them to build, but people tend to get upset when Really Important Application (sic) gets removed from under them.

As for the rest of your post. It's the usual diatribe. If you think you can do better, by all means, step up to the plate and actually _do_ something. Like yours truly has done reducing libtool to 1 version, and autoconf/automake to 2 versions (legacy and current).

Unless you're prepared to step up to the plate, offer alternate _concrete_ plans (as I have already done) and are willing to spend considerable brain and cpu cycles to get to the desired solution, you have no right to question what _is_ being done by those that _are_ doing it.

This is _not_ a democracy. The war cry of "Patches Welcome" should be obvious in that fact.

So. Let's see your patches. Seriously. Hell, if someone else takes this on (and note, it is only a matter of time before something fundamental _requires_ GNU make 3.82, so we can't just bury our heads in the sand), go for it.

Didn't think so.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 19:46, Ade Lovett wrote:
>
> On Mar 10, 2011, at 18:09 , Doug Barton wrote:
>> First, my point was not "there are going to be a lot of gmake
>> ports," my point was, "there will be>1 for a long time after it's
>> split into>1." You have now proved my point, thanks.
>
> Apples and oranges, my friend. Given the sheer amount of stuff we
> have in ports/, there is a small amount of stuff that hasn't been
> updated in forever, nor ever will be, requiring the "legacy"
> autoconf-2.13/automake-1.4

And my concern is that we're heading down the same road with gmake.
Maybe it's worth doing that, I don't know. It's hard to make an
intelligent decision when neither you nor Mark will answer what I think
is a totally reasonable question:

What is the urgency in upgrading gmake that prevents "fix the broken
ports first" as an option to at least explore?

> As for the rest of your post. It's the usual diatribe. If you think
> you can do better, by all means, step up to the plate and actually
> _do_ something.

Um, I do quite a bit, thanks. But even if I didn't, it doesn't mean that
I don't get to ask questions.

> Like yours truly has done reducing libtool to 1
> version, and autoconf/automake to 2 versions (legacy and current).

Yes, and that work has been greatly appreciated.

> Unless you're prepared to step up to the plate, offer alternate
> _concrete_ plans (as I have already done) and are willing to spend
> considerable brain and cpu cycles to get to the desired solution, you
> have no right to question what _is_ being done by those that _are_
> doing it.

Yeah, no ... that's not how this works. This is a community, with all
the problems that entails. Work on something this important should not
be happening in a vacuum. At bare minimum it's impossible to provide an
intelligent answer to the question of, "Is there a better way to do it?"
because we (the community) don't have all the facts. So what I'm asking
for as step 1 is, share the facts. Then step 2 _should be_, work
together to find the right solution. If it turns out that your idea is
actually the best one, then great, let's do it! OTOH, throwing the door
open and having the many smart people who are interested in making
FreeBSD ports better have a crack at it might just result in a
better/easier solution. It might even result in getting more volunteers
who have the desire and ability to actually help with the work. I don't
see a downside here. But if you'd like to engage in a discussion rather
than throwing around ad hominem's and pointless "patches welcome"
statements, maybe you can show me why I'm wrong.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
I answered this question last night on IRC, aDe answered it in email:

> What is the urgency in upgrading gmake that prevents "fix the broken
> ports first" as an option to at least explore?

Now that gmake is out, if the past is any indication, some project
will quickly upgrade to it. We can wait for that to happen, and then
have to scramble, or we can get ahead of the curve.

Not every single change to the Ports Collection rises to the level of
requiring a committee meeting to generate a consensus. IMHO this does
not. In this case it was "here is someone willing to do the work, here's
an action plan, let's just do it."

I've already spent nearly as much time arguing with you as I had spent
running the initial -exp run (more, if you exclude the work I did to
update the processonelog script), so I'm done here.

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 22:02 , Doug Barton wrote:
> But if you'd like to engage in a discussion rather than throwing around ad hominem's and pointless "patches welcome" statements, maybe you can show me why I'm wrong.

How about working from the basis that perhaps, just perhaps, I'm _right_, and show me why _I_ am wrong. After all, right now, I see me and a few others doing actual _work_, and others merely taking potshots.

By all means, show an alternate solution, one that assumes that some project or another, which will be a part of the FreeBSD ports collection, will _require_ GNU make 3.82, and we can go from there.

Believe me, I'm willing to listen to well thought on, start to end, include all possibility plans, but right now, all I'm seeing is "you're wrong" without anything substantial to back it up so, at this point, I'd like to focus on the issue at hand and get the work _done_.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 21:05, Mark Linimon wrote:
> I answered this question last night on IRC, aDe answered it in email:
>
>> What is the urgency in upgrading gmake that prevents "fix the broken
>> ports first" as an option to at least explore?
>
> Now that gmake is out, if the past is any indication, some project
> will quickly upgrade to it. We can wait for that to happen, and then
> have to scramble, or we can get ahead of the curve.

I can see why that would make it an important problem, but I don't see
why that makes the problem so urgent that sharing it with the community
and asking them for suggestions can't be done first; especially
considering that there is at least one workable plan in the wings if no
one comes up with something better.

> Not every single change to the Ports Collection rises to the level of
> requiring a committee meeting to generate a consensus. IMHO this does
> not.

It's really, really frustrating to me when I spend time trying to make
myself clear and you consistently mischaracterize it. I can't tell if
you're doing it on purpose, I'm failing to communicate, or something
else is going on. But just to be clear, I'm not talking about making a
committee decision. I'm talking about making the information about the
problem available to the community.

> In this case it was "here is someone willing to do the work, here's
> an action plan, let's just do it."

And while that sounds noble and all, it's the wrong road to go down.
There are way too many things happening "in private" around here and the
only way to solve that problem is to open the doors.

Meanwhile, while I appreciate you answering one of my questions, but you
still haven't answered arguably the more important one.

What harm will come from publicizing this problem and asking for help
from the community?

On 03/10/2011 21:25, Ade Lovett wrote:

> How about working from the basis that perhaps, just perhaps, I'm
> _right_, and show me why _I_ am wrong.

I can't help thinking that the fact that when I say, "Let's ask the
community for input on this topic" you _hear_ me saying, "You're wrong"
is part of the problem.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
___________________________________________________

Posted on the Freebsd-ports mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-ports to subscribe.

Work is now underway to bring GNU make 3.82 into the tree. Sadly, there are a number of rather unfortunate backwards incompatibility issues between this and 3.81 which makes a simple replacement unworkable.

A new port, devel/gmake381 has just been committed to the tree which is a heavily stripped down 3.81 version (just the binary, installed as ${LOCALBASE}/bin/gmake381, no NLS support. It is also currently marked IGNORE and is NOT attached to devel/Makefile. Please do NOT use it directly in any way, shape or form.

The next steps are as follows:

1. A patchset will be implemented, upgrading devel/gmake to 3.82, attaching devel/gmake381 to the build, and extending the USE_GMAKE variable so that a value of 'yes' will continue to use devel/gmake (now 3.82) and '381' will use the older 3.81

2. -exp runs will be iterated over to determine which ports break building with 3.82, and they will be marked as USE_GMAKE=381 to allow them to continue to build. A list of such ports will be maintained and posted.

3. devel/gmake381 will then be marked DEPRECATED with a suitable EXPIRATION_DATE (at least 6 months), at which point it will be removed, and the USE_GMAKE=381 logic also reverted, so that everything will go back to using devel/gmake. Note: it will not be necessary to edit individual port Makefiles back to USE_GMAKE=yes, since the checks for USE_GMAKE only look to see if the variable is defined. This will provide for ease of use (grep -R USE_GMAKE=381 ports/) to pick up any stragglers -- not to mention the fact that they'll most likely be broken in weird and interesting ways.

A followup posting will occur as and when steps (1) and (2) have been completed.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 09:43, Ade Lovett wrote:
> Work is now underway to bring GNU make 3.82 into the tree. Sadly,
> there are a number of rather unfortunate backwards incompatibility
> issues between this and 3.81 which makes a simple replacement
> unworkable.

Can you give us an idea of how many ports we're talking about? Rather
than having 2 gmake ports (which is likely to last for a very long time,
"best laid plans" aside) can we at least explore the idea of fixing
things that are broken to work with 3.82 first? My suggestion is to do
the -exp run, then post here and to maintainers of broken ports directly
and see what a reasonable time frame would be to get things fixed the
right way first.

My understanding is that there is _currently_ no pressure to get gmake
upgraded, so at least exploring the idea of doing it without a kludge
seems reasonable to me, although I'm happy to be proven wrong.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 13:24 , Doug Barton wrote:
> Can you give us an idea of how many ports we're talking about? Rather than having 2 gmake ports (which is likely to last for a very long time, "best laid plans" aside) can we at least explore the idea of fixing things that are broken to work with 3.82 first? My suggestion is to do the -exp run, then post here and to maintainers of broken ports directly and see what a reasonable time frame would be to get things fixed the right way first.

Preliminary runs show ~50 ports that break with 3.82, some of them unfortunately being dependencies for a reasonable number of others. An -exp has already been run, though there were a number of false positives for whatever reason.

There will absolutely _not_ be two gmake ports for anything more than a suitable deprecation period (if it is determined to move ahead) or for perhaps a month (specifically note that devel/gmake381 is marked IGNORE and not attached to the tree, so anyone trying to use it will have ... problems) if it's too much in the way of hacking.

> My understanding is that there is _currently_ no pressure to get gmake upgraded, so at least exploring the idea of doing it without a kludge seems reasonable to me, although I'm happy to be proven wrong.

The "kludge", in terms of actually testing things to get empirical data, rather than hand-waving about the sky falling, is ~4 lines of code in bsd.port.mk. We have a plan, we're going to get the results of that plan, and then do some analysis on it. Working closely with the pkgsrc tree that already _is_ at gmake-3.82

You may find a more productive approach would be to wander over to the gnumake mailing list, and ask why such a massive amount of backwards incompatibility was introduced in a minor version upgrade. Of course, that's entirely your prerogative. In the meantime, I along with a few others are actually going to _do_ the work involved in _testing_ the _possibility_ of this instead of sitting in our armchairs.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 12:05, Ade Lovett wrote:
>
> On Mar 10, 2011, at 13:24 , Doug Barton wrote:
>> Can you give us an idea of how many ports we're talking about?
>> Rather than having 2 gmake ports (which is likely to last for a
>> very long time, "best laid plans" aside) can we at least explore
>> the idea of fixing things that are broken to work with 3.82 first?
>> My suggestion is to do the -exp run, then post here and to
>> maintainers of broken ports directly and see what a reasonable time
>> frame would be to get things fixed the right way first.
>
> Preliminary runs show ~50 ports that break with 3.82, some of them
> unfortunately being dependencies for a reasonable number of others.
> An -exp has already been run, though there were a number of false
> positives for whatever reason.

What I'm suggesting is that the URL for the logs of that run get posted
here, along with contacting the maintainers of the affected ports. Then
let's see what people have to say about getting them fixed sooner rather
than later. Can you explain why doing that would be a bad idea?

> There will absolutely _not_ be two gmake ports for anything more than
> a suitable deprecation period

I admire your optimism, however experience tells us that once these
types of accomodations get into the tree, they stay there for a long time.

>> My understanding is that there is _currently_ no pressure to get
>> gmake upgraded, so at least exploring the idea of doing it without
>> a kludge seems reasonable to me, although I'm happy to be proven
>> wrong.
>
> The "kludge", in terms of actually testing things to get empirical
> data, rather than hand-waving about the sky falling,

Um, no one said the sky is falling, and you've reacted emotionally to
the term "kludge" rather than answering my question about what the
urgency is to get the update done.

> We have a plan, we're going to get the results
> of that plan, and then do some analysis on it.

And my concern is that the plan seems to have been formulated without
wider input from the community. So I ask again ... what harm can come
from at least trying to fix the broken ports first?


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 14:21 , Doug Barton wrote:
> What I'm suggesting is that the URL for the logs of that run get posted here, along with contacting the maintainers of the affected ports. Then let's see what people have to say about getting them fixed sooner rather than later. Can you explain why doing that would be a bad idea?

Those 50 or so ports are not the complete picture. Some of them are preventing other ports from being built. So, we cycle through an -exp run adding USE_GMAKE=381 (it's not a library or anything, just an executable, and in the context of clean building, only one or the other will exist for a specific port -exp build, so there's no question of interaction) until we have _all_ of the affected ports.

Then the list gets posted somewhere, USE_GMAKE=381 goes active, then there's a period (6-7 months) for folks to clean things up, at which point USE_GMAKE=381 does exactly the same as USE_GMAKE=yes (use gmake-3.82) -- ports that get fixed after this date simply change USE_GMAKE=381 -> USE_GMAKE=yes (cosmetic change only), and a list of known-broken ports can still be determined by grepping for 'USE_GMAKE=381'. If updates to those ports fix them, change USE_GMAKE back to 'yes'.

> I admire your optimism, however experience tells us that once these types of accomodations get into the tree, they stay there for a long time.

There is no issue of optimism about it. gmake-3.82 _will_ be the sole version of GNU make in the tree by (at latest) the end of this year.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 12:52, Ade Lovett wrote:
>
> On Mar 10, 2011, at 14:21 , Doug Barton wrote:
>> What I'm suggesting is that the URL for the logs of that run get
>> posted here, along with contacting the maintainers of the affected
>> ports. Then let's see what people have to say about getting them
>> fixed sooner rather than later. Can you explain why doing that
>> would be a bad idea?
>
> Those 50 or so ports are not the complete picture. Some of them are
> preventing other ports from being built. So, we cycle through an
> -exp run adding USE_GMAKE=381 (it's not a library or anything, just
> an executable, and in the context of clean building, only one or the
> other will exist for a specific port -exp build, so there's no
> question of interaction) until we have _all_ of the affected ports.
>
> Then the list gets posted somewhere,

Great!

> USE_GMAKE=381 goes active,

That's the bit that we disagree on, but your unwillingness to answer the
question I've posed twice now tells me clearly that you are determined
to follow this course of action, so I give up.

>> I admire your optimism, however experience tells us that once these
>> types of accomodations get into the tree, they stay there for a
>> long time.
>
> There is no issue of optimism about it. gmake-3.82 _will_ be the
> sole version of GNU make in the tree by (at latest) the end of this
> year.

You've already slipped your deadline from 6 months firm, to 6-7 months,
now to 9 months in the course of just a few emails. I'd be willing to
wager $BEVERAGE of your choice that we enter 2012 with multiple gmakes
in the ports tree. But like I said, I'd be glad to be proven wrong. :)


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On Thu, Mar 10, 2011 at 02:05:50PM -0600, Ade Lovett wrote:
> Preliminary runs show ~50 ports that break with 3.82, some of them
> unfortunately being dependencies for a reasonable number of others.

For values of "reasonable" in the ~1100 range.

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On Mar 10, 2011, at 14:21 , Doug Barton wrote:
> I admire your optimism, however experience tells us that once these
> types of accomodations get into the tree, they stay there for a long
> time.

Here's what I have on my system:

devel/autoconf
devel/autoconf213
devel/automake
devel/automake14
devel/autotools
devel/libtool

(That's not counting the -wrapper convenience ports.)

So: one antiquated version each of autoconf and automake.

$ dependson autoconf-2.1 | wc -l
73
$ dependson autoconf | wc -l
910
$ dependson automake-1.4 | wc -l
31
$ dependson automake | wc -l
325

('dependson' is just a script that greps INDEX.)

Summary: there used to be a lot of auto* ports. There aren't, now.

Anyone interested in looking through the sordid details can find them at
http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/ .

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

Mark Linimon writes:

> Summary: there used to be a lot of auto* ports. There aren't,
> now.

Am I correct in remembering the "used to be" period covered
2+(+) years?


Robert "sure seemed like it :-)" Huff


_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 15:54, Mark Linimon wrote:
> On Mar 10, 2011, at 14:21 , Doug Barton wrote:
>> I admire your optimism, however experience tells us that once these
>> types of accomodations get into the tree, they stay there for a long
>> time.
>
> Here's what I have on my system:
>
> devel/autoconf
> devel/autoconf213
> devel/automake
> devel/automake14
> devel/autotools
> devel/libtool
>
> (That's not counting the -wrapper convenience ports.)

[snip]

> Summary: there used to be a lot of auto* ports. There aren't, now.

First, my point was not "there are going to be a lot of gmake ports," my
point was, "there will be >1 for a long time after it's split into >1."
You have now proved my point, thanks. While we're discussing anecdotal
evidence:

autoconf-2.13.000227_6
autoconf-2.68

automake-1.4.6_6
automake-1.11.1

But that's only because I periodically do 'pkg_delete auto*' so this is
not really representative.

Meanwhile, this is why I reacted so strongly on IRC when it was
suggested that bifurcating gmake was the way to go. I was 100% certain
at the time that it was a foregone conclusion.

So maybe you will take a stab at my real question, what is the urgency
in upgrading gmake that prevents "fix the broken ports first" as an
option to at least explore? And while we're at it, if you have already
done the iterative -exp runs to get the 1100 ports figure, where are
those logs?


Thanks,

Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 18:09 , Doug Barton wrote:
> First, my point was not "there are going to be a lot of gmake ports," my point was, "there will be >1 for a long time after it's split into >1." You have now proved my point, thanks.

Apples and oranges, my friend. Given the sheer amount of stuff we have in ports/, there is a small amount of stuff that hasn't been updated in forever, nor ever will be, requiring the "legacy" autoconf-2.13/automake-1.4

Go look up pkgsrc. Or any Linux distribution. You'll find both of them lying there. I'd love to nuke them, and those ports that require them to build, but people tend to get upset when Really Important Application (sic) gets removed from under them.

As for the rest of your post. It's the usual diatribe. If you think you can do better, by all means, step up to the plate and actually _do_ something. Like yours truly has done reducing libtool to 1 version, and autoconf/automake to 2 versions (legacy and current).

Unless you're prepared to step up to the plate, offer alternate _concrete_ plans (as I have already done) and are willing to spend considerable brain and cpu cycles to get to the desired solution, you have no right to question what _is_ being done by those that _are_ doing it.

This is _not_ a democracy. The war cry of "Patches Welcome" should be obvious in that fact.

So. Let's see your patches. Seriously. Hell, if someone else takes this on (and note, it is only a matter of time before something fundamental _requires_ GNU make 3.82, so we can't just bury our heads in the sand), go for it.

Didn't think so.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 19:46, Ade Lovett wrote:
>
> On Mar 10, 2011, at 18:09 , Doug Barton wrote:
>> First, my point was not "there are going to be a lot of gmake
>> ports," my point was, "there will be>1 for a long time after it's
>> split into>1." You have now proved my point, thanks.
>
> Apples and oranges, my friend. Given the sheer amount of stuff we
> have in ports/, there is a small amount of stuff that hasn't been
> updated in forever, nor ever will be, requiring the "legacy"
> autoconf-2.13/automake-1.4

And my concern is that we're heading down the same road with gmake.
Maybe it's worth doing that, I don't know. It's hard to make an
intelligent decision when neither you nor Mark will answer what I think
is a totally reasonable question:

What is the urgency in upgrading gmake that prevents "fix the broken
ports first" as an option to at least explore?

> As for the rest of your post. It's the usual diatribe. If you think
> you can do better, by all means, step up to the plate and actually
> _do_ something.

Um, I do quite a bit, thanks. But even if I didn't, it doesn't mean that
I don't get to ask questions.

> Like yours truly has done reducing libtool to 1
> version, and autoconf/automake to 2 versions (legacy and current).

Yes, and that work has been greatly appreciated.

> Unless you're prepared to step up to the plate, offer alternate
> _concrete_ plans (as I have already done) and are willing to spend
> considerable brain and cpu cycles to get to the desired solution, you
> have no right to question what _is_ being done by those that _are_
> doing it.

Yeah, no ... that's not how this works. This is a community, with all
the problems that entails. Work on something this important should not
be happening in a vacuum. At bare minimum it's impossible to provide an
intelligent answer to the question of, "Is there a better way to do it?"
because we (the community) don't have all the facts. So what I'm asking
for as step 1 is, share the facts. Then step 2 _should be_, work
together to find the right solution. If it turns out that your idea is
actually the best one, then great, let's do it! OTOH, throwing the door
open and having the many smart people who are interested in making
FreeBSD ports better have a crack at it might just result in a
better/easier solution. It might even result in getting more volunteers
who have the desire and ability to actually help with the work. I don't
see a downside here. But if you'd like to engage in a discussion rather
than throwing around ad hominem's and pointless "patches welcome"
statements, maybe you can show me why I'm wrong.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
I answered this question last night on IRC, aDe answered it in email:

> What is the urgency in upgrading gmake that prevents "fix the broken
> ports first" as an option to at least explore?

Now that gmake is out, if the past is any indication, some project
will quickly upgrade to it. We can wait for that to happen, and then
have to scramble, or we can get ahead of the curve.

Not every single change to the Ports Collection rises to the level of
requiring a committee meeting to generate a consensus. IMHO this does
not. In this case it was "here is someone willing to do the work, here's
an action plan, let's just do it."

I've already spent nearly as much time arguing with you as I had spent
running the initial -exp run (more, if you exclude the work I did to
update the processonelog script), so I'm done here.

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 22:02 , Doug Barton wrote:
> But if you'd like to engage in a discussion rather than throwing around ad hominem's and pointless "patches welcome" statements, maybe you can show me why I'm wrong.

How about working from the basis that perhaps, just perhaps, I'm _right_, and show me why _I_ am wrong. After all, right now, I see me and a few others doing actual _work_, and others merely taking potshots.

By all means, show an alternate solution, one that assumes that some project or another, which will be a part of the FreeBSD ports collection, will _require_ GNU make 3.82, and we can go from there.

Believe me, I'm willing to listen to well thought on, start to end, include all possibility plans, but right now, all I'm seeing is "you're wrong" without anything substantial to back it up so, at this point, I'd like to focus on the issue at hand and get the work _done_.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 21:05, Mark Linimon wrote:
> I answered this question last night on IRC, aDe answered it in email:
>
>> What is the urgency in upgrading gmake that prevents "fix the broken
>> ports first" as an option to at least explore?
>
> Now that gmake is out, if the past is any indication, some project
> will quickly upgrade to it. We can wait for that to happen, and then
> have to scramble, or we can get ahead of the curve.

I can see why that would make it an important problem, but I don't see
why that makes the problem so urgent that sharing it with the community
and asking them for suggestions can't be done first; especially
considering that there is at least one workable plan in the wings if no
one comes up with something better.

> Not every single change to the Ports Collection rises to the level of
> requiring a committee meeting to generate a consensus. IMHO this does
> not.

It's really, really frustrating to me when I spend time trying to make
myself clear and you consistently mischaracterize it. I can't tell if
you're doing it on purpose, I'm failing to communicate, or something
else is going on. But just to be clear, I'm not talking about making a
committee decision. I'm talking about making the information about the
problem available to the community.

> In this case it was "here is someone willing to do the work, here's
> an action plan, let's just do it."

And while that sounds noble and all, it's the wrong road to go down.
There are way too many things happening "in private" around here and the
only way to solve that problem is to open the doors.

Meanwhile, while I appreciate you answering one of my questions, but you
still haven't answered arguably the more important one.

What harm will come from publicizing this problem and asking for help
from the community?

On 03/10/2011 21:25, Ade Lovett wrote:

> How about working from the basis that perhaps, just perhaps, I'm
> _right_, and show me why _I_ am wrong.

I can't help thinking that the fact that when I say, "Let's ask the
community for input on this topic" you _hear_ me saying, "You're wrong"
is part of the problem.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
___________________________________________________

Posted on the Freebsd-ports mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-ports to subscribe. On Thu, Mar 10, 2011 at 11:43 AM, Ade Lovett <> wrote:
> Work is now underway to bring GNU make 3.82 into the tree.  Sadly, there are a number of rather unfortunate backwards incompatibility issues between this and 3.81 which makes a simple replacement unworkable.
>
> A new port, devel/gmake381 has just been committed to the tree which is a heavily stripped down 3.81 version (just the binary, installed as ${LOCALBASE}/bin/gmake381, no NLS support.   It is also currently marked IGNORE and is NOT attached to devel/Makefile.   Please do NOT use it directly in any way, shape or form.
>
> The next steps are as follows:
>
> 1.  A patchset will be implemented, upgrading devel/gmake to 3.82, attaching devel/gmake381 to the build, and extending the USE_GMAKE variable so that a value of 'yes' will continue to use devel/gmake (now 3.82) and '381' will use the older 3.81
>
> 2.  -exp runs will be iterated over to determine which ports break building with 3.82, and they will be marked as USE_GMAKE=381 to allow them to continue to build.  A list of such ports will be maintained and posted.
>
> 3.  devel/gmake381 will then be marked DEPRECATED with a suitable EXPIRATION_DATE (at least 6 months), at which point it will be removed, and the USE_GMAKE=381 logic also reverted, so that everything will go back to using devel/gmake.  Note: it will not be necessary to edit individual port Makefiles back to USE_GMAKE=yes, since the checks for USE_GMAKE only look to see if the variable is defined.  This will provide for ease of use (grep -R USE_GMAKE=381 ports/) to pick up any stragglers -- not to mention the fact that they'll most likely be broken in weird and interesting ways.
>
> A followup posting will occur as and when steps (1) and (2) have been completed.

You can remove devel/ORBit and irc/xchat-gnome from your patch. I have
fixed those ports to build with gmake 3.82.

Cheers,
Mezz

> -aDe


--
-
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ -
_______________________________________________
___________________________________________________

Posted on the Freebsd-ports mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-ports to subscribe.

Work is now underway to bring GNU make 3.82 into the tree. Sadly, there are a number of rather unfortunate backwards incompatibility issues between this and 3.81 which makes a simple replacement unworkable.

A new port, devel/gmake381 has just been committed to the tree which is a heavily stripped down 3.81 version (just the binary, installed as ${LOCALBASE}/bin/gmake381, no NLS support. It is also currently marked IGNORE and is NOT attached to devel/Makefile. Please do NOT use it directly in any way, shape or form.

The next steps are as follows:

1. A patchset will be implemented, upgrading devel/gmake to 3.82, attaching devel/gmake381 to the build, and extending the USE_GMAKE variable so that a value of 'yes' will continue to use devel/gmake (now 3.82) and '381' will use the older 3.81

2. -exp runs will be iterated over to determine which ports break building with 3.82, and they will be marked as USE_GMAKE=381 to allow them to continue to build. A list of such ports will be maintained and posted.

3. devel/gmake381 will then be marked DEPRECATED with a suitable EXPIRATION_DATE (at least 6 months), at which point it will be removed, and the USE_GMAKE=381 logic also reverted, so that everything will go back to using devel/gmake. Note: it will not be necessary to edit individual port Makefiles back to USE_GMAKE=yes, since the checks for USE_GMAKE only look to see if the variable is defined. This will provide for ease of use (grep -R USE_GMAKE=381 ports/) to pick up any stragglers -- not to mention the fact that they'll most likely be broken in weird and interesting ways.

A followup posting will occur as and when steps (1) and (2) have been completed.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 09:43, Ade Lovett wrote:
> Work is now underway to bring GNU make 3.82 into the tree. Sadly,
> there are a number of rather unfortunate backwards incompatibility
> issues between this and 3.81 which makes a simple replacement
> unworkable.

Can you give us an idea of how many ports we're talking about? Rather
than having 2 gmake ports (which is likely to last for a very long time,
"best laid plans" aside) can we at least explore the idea of fixing
things that are broken to work with 3.82 first? My suggestion is to do
the -exp run, then post here and to maintainers of broken ports directly
and see what a reasonable time frame would be to get things fixed the
right way first.

My understanding is that there is _currently_ no pressure to get gmake
upgraded, so at least exploring the idea of doing it without a kludge
seems reasonable to me, although I'm happy to be proven wrong.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 13:24 , Doug Barton wrote:
> Can you give us an idea of how many ports we're talking about? Rather than having 2 gmake ports (which is likely to last for a very long time, "best laid plans" aside) can we at least explore the idea of fixing things that are broken to work with 3.82 first? My suggestion is to do the -exp run, then post here and to maintainers of broken ports directly and see what a reasonable time frame would be to get things fixed the right way first.

Preliminary runs show ~50 ports that break with 3.82, some of them unfortunately being dependencies for a reasonable number of others. An -exp has already been run, though there were a number of false positives for whatever reason.

There will absolutely _not_ be two gmake ports for anything more than a suitable deprecation period (if it is determined to move ahead) or for perhaps a month (specifically note that devel/gmake381 is marked IGNORE and not attached to the tree, so anyone trying to use it will have ... problems) if it's too much in the way of hacking.

> My understanding is that there is _currently_ no pressure to get gmake upgraded, so at least exploring the idea of doing it without a kludge seems reasonable to me, although I'm happy to be proven wrong.

The "kludge", in terms of actually testing things to get empirical data, rather than hand-waving about the sky falling, is ~4 lines of code in bsd.port.mk. We have a plan, we're going to get the results of that plan, and then do some analysis on it. Working closely with the pkgsrc tree that already _is_ at gmake-3.82

You may find a more productive approach would be to wander over to the gnumake mailing list, and ask why such a massive amount of backwards incompatibility was introduced in a minor version upgrade. Of course, that's entirely your prerogative. In the meantime, I along with a few others are actually going to _do_ the work involved in _testing_ the _possibility_ of this instead of sitting in our armchairs.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 12:05, Ade Lovett wrote:
>
> On Mar 10, 2011, at 13:24 , Doug Barton wrote:
>> Can you give us an idea of how many ports we're talking about?
>> Rather than having 2 gmake ports (which is likely to last for a
>> very long time, "best laid plans" aside) can we at least explore
>> the idea of fixing things that are broken to work with 3.82 first?
>> My suggestion is to do the -exp run, then post here and to
>> maintainers of broken ports directly and see what a reasonable time
>> frame would be to get things fixed the right way first.
>
> Preliminary runs show ~50 ports that break with 3.82, some of them
> unfortunately being dependencies for a reasonable number of others.
> An -exp has already been run, though there were a number of false
> positives for whatever reason.

What I'm suggesting is that the URL for the logs of that run get posted
here, along with contacting the maintainers of the affected ports. Then
let's see what people have to say about getting them fixed sooner rather
than later. Can you explain why doing that would be a bad idea?

> There will absolutely _not_ be two gmake ports for anything more than
> a suitable deprecation period

I admire your optimism, however experience tells us that once these
types of accomodations get into the tree, they stay there for a long time.

>> My understanding is that there is _currently_ no pressure to get
>> gmake upgraded, so at least exploring the idea of doing it without
>> a kludge seems reasonable to me, although I'm happy to be proven
>> wrong.
>
> The "kludge", in terms of actually testing things to get empirical
> data, rather than hand-waving about the sky falling,

Um, no one said the sky is falling, and you've reacted emotionally to
the term "kludge" rather than answering my question about what the
urgency is to get the update done.

> We have a plan, we're going to get the results
> of that plan, and then do some analysis on it.

And my concern is that the plan seems to have been formulated without
wider input from the community. So I ask again ... what harm can come
from at least trying to fix the broken ports first?


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 14:21 , Doug Barton wrote:
> What I'm suggesting is that the URL for the logs of that run get posted here, along with contacting the maintainers of the affected ports. Then let's see what people have to say about getting them fixed sooner rather than later. Can you explain why doing that would be a bad idea?

Those 50 or so ports are not the complete picture. Some of them are preventing other ports from being built. So, we cycle through an -exp run adding USE_GMAKE=381 (it's not a library or anything, just an executable, and in the context of clean building, only one or the other will exist for a specific port -exp build, so there's no question of interaction) until we have _all_ of the affected ports.

Then the list gets posted somewhere, USE_GMAKE=381 goes active, then there's a period (6-7 months) for folks to clean things up, at which point USE_GMAKE=381 does exactly the same as USE_GMAKE=yes (use gmake-3.82) -- ports that get fixed after this date simply change USE_GMAKE=381 -> USE_GMAKE=yes (cosmetic change only), and a list of known-broken ports can still be determined by grepping for 'USE_GMAKE=381'. If updates to those ports fix them, change USE_GMAKE back to 'yes'.

> I admire your optimism, however experience tells us that once these types of accomodations get into the tree, they stay there for a long time.

There is no issue of optimism about it. gmake-3.82 _will_ be the sole version of GNU make in the tree by (at latest) the end of this year.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 12:52, Ade Lovett wrote:
>
> On Mar 10, 2011, at 14:21 , Doug Barton wrote:
>> What I'm suggesting is that the URL for the logs of that run get
>> posted here, along with contacting the maintainers of the affected
>> ports. Then let's see what people have to say about getting them
>> fixed sooner rather than later. Can you explain why doing that
>> would be a bad idea?
>
> Those 50 or so ports are not the complete picture. Some of them are
> preventing other ports from being built. So, we cycle through an
> -exp run adding USE_GMAKE=381 (it's not a library or anything, just
> an executable, and in the context of clean building, only one or the
> other will exist for a specific port -exp build, so there's no
> question of interaction) until we have _all_ of the affected ports.
>
> Then the list gets posted somewhere,

Great!

> USE_GMAKE=381 goes active,

That's the bit that we disagree on, but your unwillingness to answer the
question I've posed twice now tells me clearly that you are determined
to follow this course of action, so I give up.

>> I admire your optimism, however experience tells us that once these
>> types of accomodations get into the tree, they stay there for a
>> long time.
>
> There is no issue of optimism about it. gmake-3.82 _will_ be the
> sole version of GNU make in the tree by (at latest) the end of this
> year.

You've already slipped your deadline from 6 months firm, to 6-7 months,
now to 9 months in the course of just a few emails. I'd be willing to
wager $BEVERAGE of your choice that we enter 2012 with multiple gmakes
in the ports tree. But like I said, I'd be glad to be proven wrong. :)


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On Thu, Mar 10, 2011 at 02:05:50PM -0600, Ade Lovett wrote:
> Preliminary runs show ~50 ports that break with 3.82, some of them
> unfortunately being dependencies for a reasonable number of others.

For values of "reasonable" in the ~1100 range.

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On Mar 10, 2011, at 14:21 , Doug Barton wrote:
> I admire your optimism, however experience tells us that once these
> types of accomodations get into the tree, they stay there for a long
> time.

Here's what I have on my system:

devel/autoconf
devel/autoconf213
devel/automake
devel/automake14
devel/autotools
devel/libtool

(That's not counting the -wrapper convenience ports.)

So: one antiquated version each of autoconf and automake.

$ dependson autoconf-2.1 | wc -l
73
$ dependson autoconf | wc -l
910
$ dependson automake-1.4 | wc -l
31
$ dependson automake | wc -l
325

('dependson' is just a script that greps INDEX.)

Summary: there used to be a lot of auto* ports. There aren't, now.

Anyone interested in looking through the sordid details can find them at
http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/ .

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

Mark Linimon writes:

> Summary: there used to be a lot of auto* ports. There aren't,
> now.

Am I correct in remembering the "used to be" period covered
2+(+) years?


Robert "sure seemed like it :-)" Huff


_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 15:54, Mark Linimon wrote:
> On Mar 10, 2011, at 14:21 , Doug Barton wrote:
>> I admire your optimism, however experience tells us that once these
>> types of accomodations get into the tree, they stay there for a long
>> time.
>
> Here's what I have on my system:
>
> devel/autoconf
> devel/autoconf213
> devel/automake
> devel/automake14
> devel/autotools
> devel/libtool
>
> (That's not counting the -wrapper convenience ports.)

[snip]

> Summary: there used to be a lot of auto* ports. There aren't, now.

First, my point was not "there are going to be a lot of gmake ports," my
point was, "there will be >1 for a long time after it's split into >1."
You have now proved my point, thanks. While we're discussing anecdotal
evidence:

autoconf-2.13.000227_6
autoconf-2.68

automake-1.4.6_6
automake-1.11.1

But that's only because I periodically do 'pkg_delete auto*' so this is
not really representative.

Meanwhile, this is why I reacted so strongly on IRC when it was
suggested that bifurcating gmake was the way to go. I was 100% certain
at the time that it was a foregone conclusion.

So maybe you will take a stab at my real question, what is the urgency
in upgrading gmake that prevents "fix the broken ports first" as an
option to at least explore? And while we're at it, if you have already
done the iterative -exp runs to get the 1100 ports figure, where are
those logs?


Thanks,

Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 18:09 , Doug Barton wrote:
> First, my point was not "there are going to be a lot of gmake ports," my point was, "there will be >1 for a long time after it's split into >1." You have now proved my point, thanks.

Apples and oranges, my friend. Given the sheer amount of stuff we have in ports/, there is a small amount of stuff that hasn't been updated in forever, nor ever will be, requiring the "legacy" autoconf-2.13/automake-1.4

Go look up pkgsrc. Or any Linux distribution. You'll find both of them lying there. I'd love to nuke them, and those ports that require them to build, but people tend to get upset when Really Important Application (sic) gets removed from under them.

As for the rest of your post. It's the usual diatribe. If you think you can do better, by all means, step up to the plate and actually _do_ something. Like yours truly has done reducing libtool to 1 version, and autoconf/automake to 2 versions (legacy and current).

Unless you're prepared to step up to the plate, offer alternate _concrete_ plans (as I have already done) and are willing to spend considerable brain and cpu cycles to get to the desired solution, you have no right to question what _is_ being done by those that _are_ doing it.

This is _not_ a democracy. The war cry of "Patches Welcome" should be obvious in that fact.

So. Let's see your patches. Seriously. Hell, if someone else takes this on (and note, it is only a matter of time before something fundamental _requires_ GNU make 3.82, so we can't just bury our heads in the sand), go for it.

Didn't think so.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 19:46, Ade Lovett wrote:
>
> On Mar 10, 2011, at 18:09 , Doug Barton wrote:
>> First, my point was not "there are going to be a lot of gmake
>> ports," my point was, "there will be>1 for a long time after it's
>> split into>1." You have now proved my point, thanks.
>
> Apples and oranges, my friend. Given the sheer amount of stuff we
> have in ports/, there is a small amount of stuff that hasn't been
> updated in forever, nor ever will be, requiring the "legacy"
> autoconf-2.13/automake-1.4

And my concern is that we're heading down the same road with gmake.
Maybe it's worth doing that, I don't know. It's hard to make an
intelligent decision when neither you nor Mark will answer what I think
is a totally reasonable question:

What is the urgency in upgrading gmake that prevents "fix the broken
ports first" as an option to at least explore?

> As for the rest of your post. It's the usual diatribe. If you think
> you can do better, by all means, step up to the plate and actually
> _do_ something.

Um, I do quite a bit, thanks. But even if I didn't, it doesn't mean that
I don't get to ask questions.

> Like yours truly has done reducing libtool to 1
> version, and autoconf/automake to 2 versions (legacy and current).

Yes, and that work has been greatly appreciated.

> Unless you're prepared to step up to the plate, offer alternate
> _concrete_ plans (as I have already done) and are willing to spend
> considerable brain and cpu cycles to get to the desired solution, you
> have no right to question what _is_ being done by those that _are_
> doing it.

Yeah, no ... that's not how this works. This is a community, with all
the problems that entails. Work on something this important should not
be happening in a vacuum. At bare minimum it's impossible to provide an
intelligent answer to the question of, "Is there a better way to do it?"
because we (the community) don't have all the facts. So what I'm asking
for as step 1 is, share the facts. Then step 2 _should be_, work
together to find the right solution. If it turns out that your idea is
actually the best one, then great, let's do it! OTOH, throwing the door
open and having the many smart people who are interested in making
FreeBSD ports better have a crack at it might just result in a
better/easier solution. It might even result in getting more volunteers
who have the desire and ability to actually help with the work. I don't
see a downside here. But if you'd like to engage in a discussion rather
than throwing around ad hominem's and pointless "patches welcome"
statements, maybe you can show me why I'm wrong.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
I answered this question last night on IRC, aDe answered it in email:

> What is the urgency in upgrading gmake that prevents "fix the broken
> ports first" as an option to at least explore?

Now that gmake is out, if the past is any indication, some project
will quickly upgrade to it. We can wait for that to happen, and then
have to scramble, or we can get ahead of the curve.

Not every single change to the Ports Collection rises to the level of
requiring a committee meeting to generate a consensus. IMHO this does
not. In this case it was "here is someone willing to do the work, here's
an action plan, let's just do it."

I've already spent nearly as much time arguing with you as I had spent
running the initial -exp run (more, if you exclude the work I did to
update the processonelog script), so I'm done here.

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 22:02 , Doug Barton wrote:
> But if you'd like to engage in a discussion rather than throwing around ad hominem's and pointless "patches welcome" statements, maybe you can show me why I'm wrong.

How about working from the basis that perhaps, just perhaps, I'm _right_, and show me why _I_ am wrong. After all, right now, I see me and a few others doing actual _work_, and others merely taking potshots.

By all means, show an alternate solution, one that assumes that some project or another, which will be a part of the FreeBSD ports collection, will _require_ GNU make 3.82, and we can go from there.

Believe me, I'm willing to listen to well thought on, start to end, include all possibility plans, but right now, all I'm seeing is "you're wrong" without anything substantial to back it up so, at this point, I'd like to focus on the issue at hand and get the work _done_.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 21:05, Mark Linimon wrote:
> I answered this question last night on IRC, aDe answered it in email:
>
>> What is the urgency in upgrading gmake that prevents "fix the broken
>> ports first" as an option to at least explore?
>
> Now that gmake is out, if the past is any indication, some project
> will quickly upgrade to it. We can wait for that to happen, and then
> have to scramble, or we can get ahead of the curve.

I can see why that would make it an important problem, but I don't see
why that makes the problem so urgent that sharing it with the community
and asking them for suggestions can't be done first; especially
considering that there is at least one workable plan in the wings if no
one comes up with something better.

> Not every single change to the Ports Collection rises to the level of
> requiring a committee meeting to generate a consensus. IMHO this does
> not.

It's really, really frustrating to me when I spend time trying to make
myself clear and you consistently mischaracterize it. I can't tell if
you're doing it on purpose, I'm failing to communicate, or something
else is going on. But just to be clear, I'm not talking about making a
committee decision. I'm talking about making the information about the
problem available to the community.

> In this case it was "here is someone willing to do the work, here's
> an action plan, let's just do it."

And while that sounds noble and all, it's the wrong road to go down.
There are way too many things happening "in private" around here and the
only way to solve that problem is to open the doors.

Meanwhile, while I appreciate you answering one of my questions, but you
still haven't answered arguably the more important one.

What harm will come from publicizing this problem and asking for help
from the community?

On 03/10/2011 21:25, Ade Lovett wrote:

> How about working from the basis that perhaps, just perhaps, I'm
> _right_, and show me why _I_ am wrong.

I can't help thinking that the fact that when I say, "Let's ask the
community for input on this topic" you _hear_ me saying, "You're wrong"
is part of the problem.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
___________________________________________________

Posted on the Freebsd-ports mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-ports to subscribe. On Thu, Mar 10, 2011 at 11:43 AM, Ade Lovett <> wrote:
> Work is now underway to bring GNU make 3.82 into the tree.  Sadly, there are a number of rather unfortunate backwards incompatibility issues between this and 3.81 which makes a simple replacement unworkable.
>
> A new port, devel/gmake381 has just been committed to the tree which is a heavily stripped down 3.81 version (just the binary, installed as ${LOCALBASE}/bin/gmake381, no NLS support.   It is also currently marked IGNORE and is NOT attached to devel/Makefile.   Please do NOT use it directly in any way, shape or form.
>
> The next steps are as follows:
>
> 1.  A patchset will be implemented, upgrading devel/gmake to 3.82, attaching devel/gmake381 to the build, and extending the USE_GMAKE variable so that a value of 'yes' will continue to use devel/gmake (now 3.82) and '381' will use the older 3.81
>
> 2.  -exp runs will be iterated over to determine which ports break building with 3.82, and they will be marked as USE_GMAKE=381 to allow them to continue to build.  A list of such ports will be maintained and posted.
>
> 3.  devel/gmake381 will then be marked DEPRECATED with a suitable EXPIRATION_DATE (at least 6 months), at which point it will be removed, and the USE_GMAKE=381 logic also reverted, so that everything will go back to using devel/gmake.  Note: it will not be necessary to edit individual port Makefiles back to USE_GMAKE=yes, since the checks for USE_GMAKE only look to see if the variable is defined.  This will provide for ease of use (grep -R USE_GMAKE=381 ports/) to pick up any stragglers -- not to mention the fact that they'll most likely be broken in weird and interesting ways.
>
> A followup posting will occur as and when steps (1) and (2) have been completed.

You can remove devel/ORBit and irc/xchat-gnome from your patch. I have
fixed those ports to build with gmake 3.82.

Cheers,
Mezz

> -aDe


--
-
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ -
_______________________________________________
___________________________________________________

Posted on the Freebsd-ports mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-ports to subscribe. On Sat, Mar 12, 2011 at 11:48 AM, Jeremy Messenger
<> wrote:
> On Thu, Mar 10, 2011 at 11:43 AM, Ade Lovett <> wrote:
>> Work is now underway to bring GNU make 3.82 into the tree.  Sadly, there are a number of rather unfortunate backwards incompatibility issues between this and 3.81 which makes a simple replacement unworkable.
>>
>> A new port, devel/gmake381 has just been committed to the tree which is a heavily stripped down 3.81 version (just the binary, installed as ${LOCALBASE}/bin/gmake381, no NLS support.   It is also currently marked IGNORE and is NOT attached to devel/Makefile.   Please do NOT use it directly in any way, shape or form.
>>
>> The next steps are as follows:
>>
>> 1.  A patchset will be implemented, upgrading devel/gmake to 3.82, attaching devel/gmake381 to the build, and extending the USE_GMAKE variable so that a value of 'yes' will continue to use devel/gmake (now 3.82) and '381' will use the older 3.81
>>
>> 2.  -exp runs will be iterated over to determine which ports break building with 3.82, and they will be marked as USE_GMAKE=381 to allow them to continue to build.  A list of such ports will be maintained and posted.
>>
>> 3.  devel/gmake381 will then be marked DEPRECATED with a suitable EXPIRATION_DATE (at least 6 months), at which point it will be removed, and the USE_GMAKE=381 logic also reverted, so that everything will go back to using devel/gmake.  Note: it will not be necessary to edit individual port Makefiles back to USE_GMAKE=yes, since the checks for USE_GMAKE only look to see if the variable is defined.  This will provide for ease of use (grep -R USE_GMAKE=381 ports/) to pick up any stragglers -- not to mention the fact that they'll most likely be broken in weird and interesting ways.
>>
>> A followup posting will occur as and when steps (1) and (2) have been completed.
>
> You can remove devel/ORBit and irc/xchat-gnome from your patch. I have
> fixed those ports to build with gmake 3.82.

...and audio/portaudio .

> Cheers,
> Mezz
>
>> -aDe


--
-
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ -
_______________________________________________
___________________________________________________

Posted on the Freebsd-ports mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-ports to subscribe.

Work is now underway to bring GNU make 3.82 into the tree. Sadly, there are a number of rather unfortunate backwards incompatibility issues between this and 3.81 which makes a simple replacement unworkable.

A new port, devel/gmake381 has just been committed to the tree which is a heavily stripped down 3.81 version (just the binary, installed as ${LOCALBASE}/bin/gmake381, no NLS support. It is also currently marked IGNORE and is NOT attached to devel/Makefile. Please do NOT use it directly in any way, shape or form.

The next steps are as follows:

1. A patchset will be implemented, upgrading devel/gmake to 3.82, attaching devel/gmake381 to the build, and extending the USE_GMAKE variable so that a value of 'yes' will continue to use devel/gmake (now 3.82) and '381' will use the older 3.81

2. -exp runs will be iterated over to determine which ports break building with 3.82, and they will be marked as USE_GMAKE=381 to allow them to continue to build. A list of such ports will be maintained and posted.

3. devel/gmake381 will then be marked DEPRECATED with a suitable EXPIRATION_DATE (at least 6 months), at which point it will be removed, and the USE_GMAKE=381 logic also reverted, so that everything will go back to using devel/gmake. Note: it will not be necessary to edit individual port Makefiles back to USE_GMAKE=yes, since the checks for USE_GMAKE only look to see if the variable is defined. This will provide for ease of use (grep -R USE_GMAKE=381 ports/) to pick up any stragglers -- not to mention the fact that they'll most likely be broken in weird and interesting ways.

A followup posting will occur as and when steps (1) and (2) have been completed.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 09:43, Ade Lovett wrote:
> Work is now underway to bring GNU make 3.82 into the tree. Sadly,
> there are a number of rather unfortunate backwards incompatibility
> issues between this and 3.81 which makes a simple replacement
> unworkable.

Can you give us an idea of how many ports we're talking about? Rather
than having 2 gmake ports (which is likely to last for a very long time,
"best laid plans" aside) can we at least explore the idea of fixing
things that are broken to work with 3.82 first? My suggestion is to do
the -exp run, then post here and to maintainers of broken ports directly
and see what a reasonable time frame would be to get things fixed the
right way first.

My understanding is that there is _currently_ no pressure to get gmake
upgraded, so at least exploring the idea of doing it without a kludge
seems reasonable to me, although I'm happy to be proven wrong.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 13:24 , Doug Barton wrote:
> Can you give us an idea of how many ports we're talking about? Rather than having 2 gmake ports (which is likely to last for a very long time, "best laid plans" aside) can we at least explore the idea of fixing things that are broken to work with 3.82 first? My suggestion is to do the -exp run, then post here and to maintainers of broken ports directly and see what a reasonable time frame would be to get things fixed the right way first.

Preliminary runs show ~50 ports that break with 3.82, some of them unfortunately being dependencies for a reasonable number of others. An -exp has already been run, though there were a number of false positives for whatever reason.

There will absolutely _not_ be two gmake ports for anything more than a suitable deprecation period (if it is determined to move ahead) or for perhaps a month (specifically note that devel/gmake381 is marked IGNORE and not attached to the tree, so anyone trying to use it will have ... problems) if it's too much in the way of hacking.

> My understanding is that there is _currently_ no pressure to get gmake upgraded, so at least exploring the idea of doing it without a kludge seems reasonable to me, although I'm happy to be proven wrong.

The "kludge", in terms of actually testing things to get empirical data, rather than hand-waving about the sky falling, is ~4 lines of code in bsd.port.mk. We have a plan, we're going to get the results of that plan, and then do some analysis on it. Working closely with the pkgsrc tree that already _is_ at gmake-3.82

You may find a more productive approach would be to wander over to the gnumake mailing list, and ask why such a massive amount of backwards incompatibility was introduced in a minor version upgrade. Of course, that's entirely your prerogative. In the meantime, I along with a few others are actually going to _do_ the work involved in _testing_ the _possibility_ of this instead of sitting in our armchairs.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 12:05, Ade Lovett wrote:
>
> On Mar 10, 2011, at 13:24 , Doug Barton wrote:
>> Can you give us an idea of how many ports we're talking about?
>> Rather than having 2 gmake ports (which is likely to last for a
>> very long time, "best laid plans" aside) can we at least explore
>> the idea of fixing things that are broken to work with 3.82 first?
>> My suggestion is to do the -exp run, then post here and to
>> maintainers of broken ports directly and see what a reasonable time
>> frame would be to get things fixed the right way first.
>
> Preliminary runs show ~50 ports that break with 3.82, some of them
> unfortunately being dependencies for a reasonable number of others.
> An -exp has already been run, though there were a number of false
> positives for whatever reason.

What I'm suggesting is that the URL for the logs of that run get posted
here, along with contacting the maintainers of the affected ports. Then
let's see what people have to say about getting them fixed sooner rather
than later. Can you explain why doing that would be a bad idea?

> There will absolutely _not_ be two gmake ports for anything more than
> a suitable deprecation period

I admire your optimism, however experience tells us that once these
types of accomodations get into the tree, they stay there for a long time.

>> My understanding is that there is _currently_ no pressure to get
>> gmake upgraded, so at least exploring the idea of doing it without
>> a kludge seems reasonable to me, although I'm happy to be proven
>> wrong.
>
> The "kludge", in terms of actually testing things to get empirical
> data, rather than hand-waving about the sky falling,

Um, no one said the sky is falling, and you've reacted emotionally to
the term "kludge" rather than answering my question about what the
urgency is to get the update done.

> We have a plan, we're going to get the results
> of that plan, and then do some analysis on it.

And my concern is that the plan seems to have been formulated without
wider input from the community. So I ask again ... what harm can come
from at least trying to fix the broken ports first?


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 14:21 , Doug Barton wrote:
> What I'm suggesting is that the URL for the logs of that run get posted here, along with contacting the maintainers of the affected ports. Then let's see what people have to say about getting them fixed sooner rather than later. Can you explain why doing that would be a bad idea?

Those 50 or so ports are not the complete picture. Some of them are preventing other ports from being built. So, we cycle through an -exp run adding USE_GMAKE=381 (it's not a library or anything, just an executable, and in the context of clean building, only one or the other will exist for a specific port -exp build, so there's no question of interaction) until we have _all_ of the affected ports.

Then the list gets posted somewhere, USE_GMAKE=381 goes active, then there's a period (6-7 months) for folks to clean things up, at which point USE_GMAKE=381 does exactly the same as USE_GMAKE=yes (use gmake-3.82) -- ports that get fixed after this date simply change USE_GMAKE=381 -> USE_GMAKE=yes (cosmetic change only), and a list of known-broken ports can still be determined by grepping for 'USE_GMAKE=381'. If updates to those ports fix them, change USE_GMAKE back to 'yes'.

> I admire your optimism, however experience tells us that once these types of accomodations get into the tree, they stay there for a long time.

There is no issue of optimism about it. gmake-3.82 _will_ be the sole version of GNU make in the tree by (at latest) the end of this year.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 12:52, Ade Lovett wrote:
>
> On Mar 10, 2011, at 14:21 , Doug Barton wrote:
>> What I'm suggesting is that the URL for the logs of that run get
>> posted here, along with contacting the maintainers of the affected
>> ports. Then let's see what people have to say about getting them
>> fixed sooner rather than later. Can you explain why doing that
>> would be a bad idea?
>
> Those 50 or so ports are not the complete picture. Some of them are
> preventing other ports from being built. So, we cycle through an
> -exp run adding USE_GMAKE=381 (it's not a library or anything, just
> an executable, and in the context of clean building, only one or the
> other will exist for a specific port -exp build, so there's no
> question of interaction) until we have _all_ of the affected ports.
>
> Then the list gets posted somewhere,

Great!

> USE_GMAKE=381 goes active,

That's the bit that we disagree on, but your unwillingness to answer the
question I've posed twice now tells me clearly that you are determined
to follow this course of action, so I give up.

>> I admire your optimism, however experience tells us that once these
>> types of accomodations get into the tree, they stay there for a
>> long time.
>
> There is no issue of optimism about it. gmake-3.82 _will_ be the
> sole version of GNU make in the tree by (at latest) the end of this
> year.

You've already slipped your deadline from 6 months firm, to 6-7 months,
now to 9 months in the course of just a few emails. I'd be willing to
wager $BEVERAGE of your choice that we enter 2012 with multiple gmakes
in the ports tree. But like I said, I'd be glad to be proven wrong. :)


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On Thu, Mar 10, 2011 at 02:05:50PM -0600, Ade Lovett wrote:
> Preliminary runs show ~50 ports that break with 3.82, some of them
> unfortunately being dependencies for a reasonable number of others.

For values of "reasonable" in the ~1100 range.

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On Mar 10, 2011, at 14:21 , Doug Barton wrote:
> I admire your optimism, however experience tells us that once these
> types of accomodations get into the tree, they stay there for a long
> time.

Here's what I have on my system:

devel/autoconf
devel/autoconf213
devel/automake
devel/automake14
devel/autotools
devel/libtool

(That's not counting the -wrapper convenience ports.)

So: one antiquated version each of autoconf and automake.

$ dependson autoconf-2.1 | wc -l
73
$ dependson autoconf | wc -l
910
$ dependson automake-1.4 | wc -l
31
$ dependson automake | wc -l
325

('dependson' is just a script that greps INDEX.)

Summary: there used to be a lot of auto* ports. There aren't, now.

Anyone interested in looking through the sordid details can find them at
http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/ .

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

Mark Linimon writes:

> Summary: there used to be a lot of auto* ports. There aren't,
> now.

Am I correct in remembering the "used to be" period covered
2+(+) years?


Robert "sure seemed like it :-)" Huff


_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 15:54, Mark Linimon wrote:
> On Mar 10, 2011, at 14:21 , Doug Barton wrote:
>> I admire your optimism, however experience tells us that once these
>> types of accomodations get into the tree, they stay there for a long
>> time.
>
> Here's what I have on my system:
>
> devel/autoconf
> devel/autoconf213
> devel/automake
> devel/automake14
> devel/autotools
> devel/libtool
>
> (That's not counting the -wrapper convenience ports.)

[snip]

> Summary: there used to be a lot of auto* ports. There aren't, now.

First, my point was not "there are going to be a lot of gmake ports," my
point was, "there will be >1 for a long time after it's split into >1."
You have now proved my point, thanks. While we're discussing anecdotal
evidence:

autoconf-2.13.000227_6
autoconf-2.68

automake-1.4.6_6
automake-1.11.1

But that's only because I periodically do 'pkg_delete auto*' so this is
not really representative.

Meanwhile, this is why I reacted so strongly on IRC when it was
suggested that bifurcating gmake was the way to go. I was 100% certain
at the time that it was a foregone conclusion.

So maybe you will take a stab at my real question, what is the urgency
in upgrading gmake that prevents "fix the broken ports first" as an
option to at least explore? And while we're at it, if you have already
done the iterative -exp runs to get the 1100 ports figure, where are
those logs?


Thanks,

Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 18:09 , Doug Barton wrote:
> First, my point was not "there are going to be a lot of gmake ports," my point was, "there will be >1 for a long time after it's split into >1." You have now proved my point, thanks.

Apples and oranges, my friend. Given the sheer amount of stuff we have in ports/, there is a small amount of stuff that hasn't been updated in forever, nor ever will be, requiring the "legacy" autoconf-2.13/automake-1.4

Go look up pkgsrc. Or any Linux distribution. You'll find both of them lying there. I'd love to nuke them, and those ports that require them to build, but people tend to get upset when Really Important Application (sic) gets removed from under them.

As for the rest of your post. It's the usual diatribe. If you think you can do better, by all means, step up to the plate and actually _do_ something. Like yours truly has done reducing libtool to 1 version, and autoconf/automake to 2 versions (legacy and current).

Unless you're prepared to step up to the plate, offer alternate _concrete_ plans (as I have already done) and are willing to spend considerable brain and cpu cycles to get to the desired solution, you have no right to question what _is_ being done by those that _are_ doing it.

This is _not_ a democracy. The war cry of "Patches Welcome" should be obvious in that fact.

So. Let's see your patches. Seriously. Hell, if someone else takes this on (and note, it is only a matter of time before something fundamental _requires_ GNU make 3.82, so we can't just bury our heads in the sand), go for it.

Didn't think so.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 19:46, Ade Lovett wrote:
>
> On Mar 10, 2011, at 18:09 , Doug Barton wrote:
>> First, my point was not "there are going to be a lot of gmake
>> ports," my point was, "there will be>1 for a long time after it's
>> split into>1." You have now proved my point, thanks.
>
> Apples and oranges, my friend. Given the sheer amount of stuff we
> have in ports/, there is a small amount of stuff that hasn't been
> updated in forever, nor ever will be, requiring the "legacy"
> autoconf-2.13/automake-1.4

And my concern is that we're heading down the same road with gmake.
Maybe it's worth doing that, I don't know. It's hard to make an
intelligent decision when neither you nor Mark will answer what I think
is a totally reasonable question:

What is the urgency in upgrading gmake that prevents "fix the broken
ports first" as an option to at least explore?

> As for the rest of your post. It's the usual diatribe. If you think
> you can do better, by all means, step up to the plate and actually
> _do_ something.

Um, I do quite a bit, thanks. But even if I didn't, it doesn't mean that
I don't get to ask questions.

> Like yours truly has done reducing libtool to 1
> version, and autoconf/automake to 2 versions (legacy and current).

Yes, and that work has been greatly appreciated.

> Unless you're prepared to step up to the plate, offer alternate
> _concrete_ plans (as I have already done) and are willing to spend
> considerable brain and cpu cycles to get to the desired solution, you
> have no right to question what _is_ being done by those that _are_
> doing it.

Yeah, no ... that's not how this works. This is a community, with all
the problems that entails. Work on something this important should not
be happening in a vacuum. At bare minimum it's impossible to provide an
intelligent answer to the question of, "Is there a better way to do it?"
because we (the community) don't have all the facts. So what I'm asking
for as step 1 is, share the facts. Then step 2 _should be_, work
together to find the right solution. If it turns out that your idea is
actually the best one, then great, let's do it! OTOH, throwing the door
open and having the many smart people who are interested in making
FreeBSD ports better have a crack at it might just result in a
better/easier solution. It might even result in getting more volunteers
who have the desire and ability to actually help with the work. I don't
see a downside here. But if you'd like to engage in a discussion rather
than throwing around ad hominem's and pointless "patches welcome"
statements, maybe you can show me why I'm wrong.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
I answered this question last night on IRC, aDe answered it in email:

> What is the urgency in upgrading gmake that prevents "fix the broken
> ports first" as an option to at least explore?

Now that gmake is out, if the past is any indication, some project
will quickly upgrade to it. We can wait for that to happen, and then
have to scramble, or we can get ahead of the curve.

Not every single change to the Ports Collection rises to the level of
requiring a committee meeting to generate a consensus. IMHO this does
not. In this case it was "here is someone willing to do the work, here's
an action plan, let's just do it."

I've already spent nearly as much time arguing with you as I had spent
running the initial -exp run (more, if you exclude the work I did to
update the processonelog script), so I'm done here.

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 22:02 , Doug Barton wrote:
> But if you'd like to engage in a discussion rather than throwing around ad hominem's and pointless "patches welcome" statements, maybe you can show me why I'm wrong.

How about working from the basis that perhaps, just perhaps, I'm _right_, and show me why _I_ am wrong. After all, right now, I see me and a few others doing actual _work_, and others merely taking potshots.

By all means, show an alternate solution, one that assumes that some project or another, which will be a part of the FreeBSD ports collection, will _require_ GNU make 3.82, and we can go from there.

Believe me, I'm willing to listen to well thought on, start to end, include all possibility plans, but right now, all I'm seeing is "you're wrong" without anything substantial to back it up so, at this point, I'd like to focus on the issue at hand and get the work _done_.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 21:05, Mark Linimon wrote:
> I answered this question last night on IRC, aDe answered it in email:
>
>> What is the urgency in upgrading gmake that prevents "fix the broken
>> ports first" as an option to at least explore?
>
> Now that gmake is out, if the past is any indication, some project
> will quickly upgrade to it. We can wait for that to happen, and then
> have to scramble, or we can get ahead of the curve.

I can see why that would make it an important problem, but I don't see
why that makes the problem so urgent that sharing it with the community
and asking them for suggestions can't be done first; especially
considering that there is at least one workable plan in the wings if no
one comes up with something better.

> Not every single change to the Ports Collection rises to the level of
> requiring a committee meeting to generate a consensus. IMHO this does
> not.

It's really, really frustrating to me when I spend time trying to make
myself clear and you consistently mischaracterize it. I can't tell if
you're doing it on purpose, I'm failing to communicate, or something
else is going on. But just to be clear, I'm not talking about making a
committee decision. I'm talking about making the information about the
problem available to the community.

> In this case it was "here is someone willing to do the work, here's
> an action plan, let's just do it."

And while that sounds noble and all, it's the wrong road to go down.
There are way too many things happening "in private" around here and the
only way to solve that problem is to open the doors.

Meanwhile, while I appreciate you answering one of my questions, but you
still haven't answered arguably the more important one.

What harm will come from publicizing this problem and asking for help
from the community?

On 03/10/2011 21:25, Ade Lovett wrote:

> How about working from the basis that perhaps, just perhaps, I'm
> _right_, and show me why _I_ am wrong.

I can't help thinking that the fact that when I say, "Let's ask the
community for input on this topic" you _hear_ me saying, "You're wrong"
is part of the problem.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
___________________________________________________

Posted on the Freebsd-ports mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-ports to subscribe. On Thu, Mar 10, 2011 at 11:43 AM, Ade Lovett <> wrote:
> Work is now underway to bring GNU make 3.82 into the tree.  Sadly, there are a number of rather unfortunate backwards incompatibility issues between this and 3.81 which makes a simple replacement unworkable.
>
> A new port, devel/gmake381 has just been committed to the tree which is a heavily stripped down 3.81 version (just the binary, installed as ${LOCALBASE}/bin/gmake381, no NLS support.   It is also currently marked IGNORE and is NOT attached to devel/Makefile.   Please do NOT use it directly in any way, shape or form.
>
> The next steps are as follows:
>
> 1.  A patchset will be implemented, upgrading devel/gmake to 3.82, attaching devel/gmake381 to the build, and extending the USE_GMAKE variable so that a value of 'yes' will continue to use devel/gmake (now 3.82) and '381' will use the older 3.81
>
> 2.  -exp runs will be iterated over to determine which ports break building with 3.82, and they will be marked as USE_GMAKE=381 to allow them to continue to build.  A list of such ports will be maintained and posted.
>
> 3.  devel/gmake381 will then be marked DEPRECATED with a suitable EXPIRATION_DATE (at least 6 months), at which point it will be removed, and the USE_GMAKE=381 logic also reverted, so that everything will go back to using devel/gmake.  Note: it will not be necessary to edit individual port Makefiles back to USE_GMAKE=yes, since the checks for USE_GMAKE only look to see if the variable is defined.  This will provide for ease of use (grep -R USE_GMAKE=381 ports/) to pick up any stragglers -- not to mention the fact that they'll most likely be broken in weird and interesting ways.
>
> A followup posting will occur as and when steps (1) and (2) have been completed.

You can remove devel/ORBit and irc/xchat-gnome from your patch. I have
fixed those ports to build with gmake 3.82.

Cheers,
Mezz

> -aDe


--
-
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ -
_______________________________________________
___________________________________________________

Posted on the Freebsd-ports mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-ports to subscribe. On Sat, Mar 12, 2011 at 11:48 AM, Jeremy Messenger
<> wrote:
> On Thu, Mar 10, 2011 at 11:43 AM, Ade Lovett <> wrote:
>> Work is now underway to bring GNU make 3.82 into the tree.  Sadly, there are a number of rather unfortunate backwards incompatibility issues between this and 3.81 which makes a simple replacement unworkable.
>>
>> A new port, devel/gmake381 has just been committed to the tree which is a heavily stripped down 3.81 version (just the binary, installed as ${LOCALBASE}/bin/gmake381, no NLS support.   It is also currently marked IGNORE and is NOT attached to devel/Makefile.   Please do NOT use it directly in any way, shape or form.
>>
>> The next steps are as follows:
>>
>> 1.  A patchset will be implemented, upgrading devel/gmake to 3.82, attaching devel/gmake381 to the build, and extending the USE_GMAKE variable so that a value of 'yes' will continue to use devel/gmake (now 3.82) and '381' will use the older 3.81
>>
>> 2.  -exp runs will be iterated over to determine which ports break building with 3.82, and they will be marked as USE_GMAKE=381 to allow them to continue to build.  A list of such ports will be maintained and posted.
>>
>> 3.  devel/gmake381 will then be marked DEPRECATED with a suitable EXPIRATION_DATE (at least 6 months), at which point it will be removed, and the USE_GMAKE=381 logic also reverted, so that everything will go back to using devel/gmake.  Note: it will not be necessary to edit individual port Makefiles back to USE_GMAKE=yes, since the checks for USE_GMAKE only look to see if the variable is defined.  This will provide for ease of use (grep -R USE_GMAKE=381 ports/) to pick up any stragglers -- not to mention the fact that they'll most likely be broken in weird and interesting ways.
>>
>> A followup posting will occur as and when steps (1) and (2) have been completed.
>
> You can remove devel/ORBit and irc/xchat-gnome from your patch. I have
> fixed those ports to build with gmake 3.82.

...and audio/portaudio .

> Cheers,
> Mezz
>
>> -aDe


--
-
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ -
_______________________________________________
___________________________________________________

Posted on the Freebsd-ports mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-ports to subscribe. Jeremy Messenger <> wrote:

> You can remove devel/ORBit and irc/xchat-gnome from your patch. I have
> fixed those ports to build with gmake 3.82.

I fixed net/xtraceroute and deskutils/contacts and sent a patch to
the maintainer of misc/gnustep-examples... since I had those fixes
already lying around from the same issue on a !FreeBSD system.

--
Christian "naddy" Weisgerber

_______________________________________________
___________________________________________________

Posted on the Freebsd-ports mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-ports to subscribe.

Work is now underway to bring GNU make 3.82 into the tree. Sadly, there are a number of rather unfortunate backwards incompatibility issues between this and 3.81 which makes a simple replacement unworkable.

A new port, devel/gmake381 has just been committed to the tree which is a heavily stripped down 3.81 version (just the binary, installed as ${LOCALBASE}/bin/gmake381, no NLS support. It is also currently marked IGNORE and is NOT attached to devel/Makefile. Please do NOT use it directly in any way, shape or form.

The next steps are as follows:

1. A patchset will be implemented, upgrading devel/gmake to 3.82, attaching devel/gmake381 to the build, and extending the USE_GMAKE variable so that a value of 'yes' will continue to use devel/gmake (now 3.82) and '381' will use the older 3.81

2. -exp runs will be iterated over to determine which ports break building with 3.82, and they will be marked as USE_GMAKE=381 to allow them to continue to build. A list of such ports will be maintained and posted.

3. devel/gmake381 will then be marked DEPRECATED with a suitable EXPIRATION_DATE (at least 6 months), at which point it will be removed, and the USE_GMAKE=381 logic also reverted, so that everything will go back to using devel/gmake. Note: it will not be necessary to edit individual port Makefiles back to USE_GMAKE=yes, since the checks for USE_GMAKE only look to see if the variable is defined. This will provide for ease of use (grep -R USE_GMAKE=381 ports/) to pick up any stragglers -- not to mention the fact that they'll most likely be broken in weird and interesting ways.

A followup posting will occur as and when steps (1) and (2) have been completed.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 09:43, Ade Lovett wrote:
> Work is now underway to bring GNU make 3.82 into the tree. Sadly,
> there are a number of rather unfortunate backwards incompatibility
> issues between this and 3.81 which makes a simple replacement
> unworkable.

Can you give us an idea of how many ports we're talking about? Rather
than having 2 gmake ports (which is likely to last for a very long time,
"best laid plans" aside) can we at least explore the idea of fixing
things that are broken to work with 3.82 first? My suggestion is to do
the -exp run, then post here and to maintainers of broken ports directly
and see what a reasonable time frame would be to get things fixed the
right way first.

My understanding is that there is _currently_ no pressure to get gmake
upgraded, so at least exploring the idea of doing it without a kludge
seems reasonable to me, although I'm happy to be proven wrong.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 13:24 , Doug Barton wrote:
> Can you give us an idea of how many ports we're talking about? Rather than having 2 gmake ports (which is likely to last for a very long time, "best laid plans" aside) can we at least explore the idea of fixing things that are broken to work with 3.82 first? My suggestion is to do the -exp run, then post here and to maintainers of broken ports directly and see what a reasonable time frame would be to get things fixed the right way first.

Preliminary runs show ~50 ports that break with 3.82, some of them unfortunately being dependencies for a reasonable number of others. An -exp has already been run, though there were a number of false positives for whatever reason.

There will absolutely _not_ be two gmake ports for anything more than a suitable deprecation period (if it is determined to move ahead) or for perhaps a month (specifically note that devel/gmake381 is marked IGNORE and not attached to the tree, so anyone trying to use it will have ... problems) if it's too much in the way of hacking.

> My understanding is that there is _currently_ no pressure to get gmake upgraded, so at least exploring the idea of doing it without a kludge seems reasonable to me, although I'm happy to be proven wrong.

The "kludge", in terms of actually testing things to get empirical data, rather than hand-waving about the sky falling, is ~4 lines of code in bsd.port.mk. We have a plan, we're going to get the results of that plan, and then do some analysis on it. Working closely with the pkgsrc tree that already _is_ at gmake-3.82

You may find a more productive approach would be to wander over to the gnumake mailing list, and ask why such a massive amount of backwards incompatibility was introduced in a minor version upgrade. Of course, that's entirely your prerogative. In the meantime, I along with a few others are actually going to _do_ the work involved in _testing_ the _possibility_ of this instead of sitting in our armchairs.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 12:05, Ade Lovett wrote:
>
> On Mar 10, 2011, at 13:24 , Doug Barton wrote:
>> Can you give us an idea of how many ports we're talking about?
>> Rather than having 2 gmake ports (which is likely to last for a
>> very long time, "best laid plans" aside) can we at least explore
>> the idea of fixing things that are broken to work with 3.82 first?
>> My suggestion is to do the -exp run, then post here and to
>> maintainers of broken ports directly and see what a reasonable time
>> frame would be to get things fixed the right way first.
>
> Preliminary runs show ~50 ports that break with 3.82, some of them
> unfortunately being dependencies for a reasonable number of others.
> An -exp has already been run, though there were a number of false
> positives for whatever reason.

What I'm suggesting is that the URL for the logs of that run get posted
here, along with contacting the maintainers of the affected ports. Then
let's see what people have to say about getting them fixed sooner rather
than later. Can you explain why doing that would be a bad idea?

> There will absolutely _not_ be two gmake ports for anything more than
> a suitable deprecation period

I admire your optimism, however experience tells us that once these
types of accomodations get into the tree, they stay there for a long time.

>> My understanding is that there is _currently_ no pressure to get
>> gmake upgraded, so at least exploring the idea of doing it without
>> a kludge seems reasonable to me, although I'm happy to be proven
>> wrong.
>
> The "kludge", in terms of actually testing things to get empirical
> data, rather than hand-waving about the sky falling,

Um, no one said the sky is falling, and you've reacted emotionally to
the term "kludge" rather than answering my question about what the
urgency is to get the update done.

> We have a plan, we're going to get the results
> of that plan, and then do some analysis on it.

And my concern is that the plan seems to have been formulated without
wider input from the community. So I ask again ... what harm can come
from at least trying to fix the broken ports first?


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 14:21 , Doug Barton wrote:
> What I'm suggesting is that the URL for the logs of that run get posted here, along with contacting the maintainers of the affected ports. Then let's see what people have to say about getting them fixed sooner rather than later. Can you explain why doing that would be a bad idea?

Those 50 or so ports are not the complete picture. Some of them are preventing other ports from being built. So, we cycle through an -exp run adding USE_GMAKE=381 (it's not a library or anything, just an executable, and in the context of clean building, only one or the other will exist for a specific port -exp build, so there's no question of interaction) until we have _all_ of the affected ports.

Then the list gets posted somewhere, USE_GMAKE=381 goes active, then there's a period (6-7 months) for folks to clean things up, at which point USE_GMAKE=381 does exactly the same as USE_GMAKE=yes (use gmake-3.82) -- ports that get fixed after this date simply change USE_GMAKE=381 -> USE_GMAKE=yes (cosmetic change only), and a list of known-broken ports can still be determined by grepping for 'USE_GMAKE=381'. If updates to those ports fix them, change USE_GMAKE back to 'yes'.

> I admire your optimism, however experience tells us that once these types of accomodations get into the tree, they stay there for a long time.

There is no issue of optimism about it. gmake-3.82 _will_ be the sole version of GNU make in the tree by (at latest) the end of this year.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 12:52, Ade Lovett wrote:
>
> On Mar 10, 2011, at 14:21 , Doug Barton wrote:
>> What I'm suggesting is that the URL for the logs of that run get
>> posted here, along with contacting the maintainers of the affected
>> ports. Then let's see what people have to say about getting them
>> fixed sooner rather than later. Can you explain why doing that
>> would be a bad idea?
>
> Those 50 or so ports are not the complete picture. Some of them are
> preventing other ports from being built. So, we cycle through an
> -exp run adding USE_GMAKE=381 (it's not a library or anything, just
> an executable, and in the context of clean building, only one or the
> other will exist for a specific port -exp build, so there's no
> question of interaction) until we have _all_ of the affected ports.
>
> Then the list gets posted somewhere,

Great!

> USE_GMAKE=381 goes active,

That's the bit that we disagree on, but your unwillingness to answer the
question I've posed twice now tells me clearly that you are determined
to follow this course of action, so I give up.

>> I admire your optimism, however experience tells us that once these
>> types of accomodations get into the tree, they stay there for a
>> long time.
>
> There is no issue of optimism about it. gmake-3.82 _will_ be the
> sole version of GNU make in the tree by (at latest) the end of this
> year.

You've already slipped your deadline from 6 months firm, to 6-7 months,
now to 9 months in the course of just a few emails. I'd be willing to
wager $BEVERAGE of your choice that we enter 2012 with multiple gmakes
in the ports tree. But like I said, I'd be glad to be proven wrong. :)


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On Thu, Mar 10, 2011 at 02:05:50PM -0600, Ade Lovett wrote:
> Preliminary runs show ~50 ports that break with 3.82, some of them
> unfortunately being dependencies for a reasonable number of others.

For values of "reasonable" in the ~1100 range.

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On Mar 10, 2011, at 14:21 , Doug Barton wrote:
> I admire your optimism, however experience tells us that once these
> types of accomodations get into the tree, they stay there for a long
> time.

Here's what I have on my system:

devel/autoconf
devel/autoconf213
devel/automake
devel/automake14
devel/autotools
devel/libtool

(That's not counting the -wrapper convenience ports.)

So: one antiquated version each of autoconf and automake.

$ dependson autoconf-2.1 | wc -l
73
$ dependson autoconf | wc -l
910
$ dependson automake-1.4 | wc -l
31
$ dependson automake | wc -l
325

('dependson' is just a script that greps INDEX.)

Summary: there used to be a lot of auto* ports. There aren't, now.

Anyone interested in looking through the sordid details can find them at
http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/ .

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

Mark Linimon writes:

> Summary: there used to be a lot of auto* ports. There aren't,
> now.

Am I correct in remembering the "used to be" period covered
2+(+) years?


Robert "sure seemed like it :-)" Huff


_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 15:54, Mark Linimon wrote:
> On Mar 10, 2011, at 14:21 , Doug Barton wrote:
>> I admire your optimism, however experience tells us that once these
>> types of accomodations get into the tree, they stay there for a long
>> time.
>
> Here's what I have on my system:
>
> devel/autoconf
> devel/autoconf213
> devel/automake
> devel/automake14
> devel/autotools
> devel/libtool
>
> (That's not counting the -wrapper convenience ports.)

[snip]

> Summary: there used to be a lot of auto* ports. There aren't, now.

First, my point was not "there are going to be a lot of gmake ports," my
point was, "there will be >1 for a long time after it's split into >1."
You have now proved my point, thanks. While we're discussing anecdotal
evidence:

autoconf-2.13.000227_6
autoconf-2.68

automake-1.4.6_6
automake-1.11.1

But that's only because I periodically do 'pkg_delete auto*' so this is
not really representative.

Meanwhile, this is why I reacted so strongly on IRC when it was
suggested that bifurcating gmake was the way to go. I was 100% certain
at the time that it was a foregone conclusion.

So maybe you will take a stab at my real question, what is the urgency
in upgrading gmake that prevents "fix the broken ports first" as an
option to at least explore? And while we're at it, if you have already
done the iterative -exp runs to get the 1100 ports figure, where are
those logs?


Thanks,

Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 18:09 , Doug Barton wrote:
> First, my point was not "there are going to be a lot of gmake ports," my point was, "there will be >1 for a long time after it's split into >1." You have now proved my point, thanks.

Apples and oranges, my friend. Given the sheer amount of stuff we have in ports/, there is a small amount of stuff that hasn't been updated in forever, nor ever will be, requiring the "legacy" autoconf-2.13/automake-1.4

Go look up pkgsrc. Or any Linux distribution. You'll find both of them lying there. I'd love to nuke them, and those ports that require them to build, but people tend to get upset when Really Important Application (sic) gets removed from under them.

As for the rest of your post. It's the usual diatribe. If you think you can do better, by all means, step up to the plate and actually _do_ something. Like yours truly has done reducing libtool to 1 version, and autoconf/automake to 2 versions (legacy and current).

Unless you're prepared to step up to the plate, offer alternate _concrete_ plans (as I have already done) and are willing to spend considerable brain and cpu cycles to get to the desired solution, you have no right to question what _is_ being done by those that _are_ doing it.

This is _not_ a democracy. The war cry of "Patches Welcome" should be obvious in that fact.

So. Let's see your patches. Seriously. Hell, if someone else takes this on (and note, it is only a matter of time before something fundamental _requires_ GNU make 3.82, so we can't just bury our heads in the sand), go for it.

Didn't think so.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 19:46, Ade Lovett wrote:
>
> On Mar 10, 2011, at 18:09 , Doug Barton wrote:
>> First, my point was not "there are going to be a lot of gmake
>> ports," my point was, "there will be>1 for a long time after it's
>> split into>1." You have now proved my point, thanks.
>
> Apples and oranges, my friend. Given the sheer amount of stuff we
> have in ports/, there is a small amount of stuff that hasn't been
> updated in forever, nor ever will be, requiring the "legacy"
> autoconf-2.13/automake-1.4

And my concern is that we're heading down the same road with gmake.
Maybe it's worth doing that, I don't know. It's hard to make an
intelligent decision when neither you nor Mark will answer what I think
is a totally reasonable question:

What is the urgency in upgrading gmake that prevents "fix the broken
ports first" as an option to at least explore?

> As for the rest of your post. It's the usual diatribe. If you think
> you can do better, by all means, step up to the plate and actually
> _do_ something.

Um, I do quite a bit, thanks. But even if I didn't, it doesn't mean that
I don't get to ask questions.

> Like yours truly has done reducing libtool to 1
> version, and autoconf/automake to 2 versions (legacy and current).

Yes, and that work has been greatly appreciated.

> Unless you're prepared to step up to the plate, offer alternate
> _concrete_ plans (as I have already done) and are willing to spend
> considerable brain and cpu cycles to get to the desired solution, you
> have no right to question what _is_ being done by those that _are_
> doing it.

Yeah, no ... that's not how this works. This is a community, with all
the problems that entails. Work on something this important should not
be happening in a vacuum. At bare minimum it's impossible to provide an
intelligent answer to the question of, "Is there a better way to do it?"
because we (the community) don't have all the facts. So what I'm asking
for as step 1 is, share the facts. Then step 2 _should be_, work
together to find the right solution. If it turns out that your idea is
actually the best one, then great, let's do it! OTOH, throwing the door
open and having the many smart people who are interested in making
FreeBSD ports better have a crack at it might just result in a
better/easier solution. It might even result in getting more volunteers
who have the desire and ability to actually help with the work. I don't
see a downside here. But if you'd like to engage in a discussion rather
than throwing around ad hominem's and pointless "patches welcome"
statements, maybe you can show me why I'm wrong.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
I answered this question last night on IRC, aDe answered it in email:

> What is the urgency in upgrading gmake that prevents "fix the broken
> ports first" as an option to at least explore?

Now that gmake is out, if the past is any indication, some project
will quickly upgrade to it. We can wait for that to happen, and then
have to scramble, or we can get ahead of the curve.

Not every single change to the Ports Collection rises to the level of
requiring a committee meeting to generate a consensus. IMHO this does
not. In this case it was "here is someone willing to do the work, here's
an action plan, let's just do it."

I've already spent nearly as much time arguing with you as I had spent
running the initial -exp run (more, if you exclude the work I did to
update the processonelog script), so I'm done here.

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 22:02 , Doug Barton wrote:
> But if you'd like to engage in a discussion rather than throwing around ad hominem's and pointless "patches welcome" statements, maybe you can show me why I'm wrong.

How about working from the basis that perhaps, just perhaps, I'm _right_, and show me why _I_ am wrong. After all, right now, I see me and a few others doing actual _work_, and others merely taking potshots.

By all means, show an alternate solution, one that assumes that some project or another, which will be a part of the FreeBSD ports collection, will _require_ GNU make 3.82, and we can go from there.

Believe me, I'm willing to listen to well thought on, start to end, include all possibility plans, but right now, all I'm seeing is "you're wrong" without anything substantial to back it up so, at this point, I'd like to focus on the issue at hand and get the work _done_.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 21:05, Mark Linimon wrote:
> I answered this question last night on IRC, aDe answered it in email:
>
>> What is the urgency in upgrading gmake that prevents "fix the broken
>> ports first" as an option to at least explore?
>
> Now that gmake is out, if the past is any indication, some project
> will quickly upgrade to it. We can wait for that to happen, and then
> have to scramble, or we can get ahead of the curve.

I can see why that would make it an important problem, but I don't see
why that makes the problem so urgent that sharing it with the community
and asking them for suggestions can't be done first; especially
considering that there is at least one workable plan in the wings if no
one comes up with something better.

> Not every single change to the Ports Collection rises to the level of
> requiring a committee meeting to generate a consensus. IMHO this does
> not.

It's really, really frustrating to me when I spend time trying to make
myself clear and you consistently mischaracterize it. I can't tell if
you're doing it on purpose, I'm failing to communicate, or something
else is going on. But just to be clear, I'm not talking about making a
committee decision. I'm talking about making the information about the
problem available to the community.

> In this case it was "here is someone willing to do the work, here's
> an action plan, let's just do it."

And while that sounds noble and all, it's the wrong road to go down.
There are way too many things happening "in private" around here and the
only way to solve that problem is to open the doors.

Meanwhile, while I appreciate you answering one of my questions, but you
still haven't answered arguably the more important one.

What harm will come from publicizing this problem and asking for help
from the community?

On 03/10/2011 21:25, Ade Lovett wrote:

> How about working from the basis that perhaps, just perhaps, I'm
> _right_, and show me why _I_ am wrong.

I can't help thinking that the fact that when I say, "Let's ask the
community for input on this topic" you _hear_ me saying, "You're wrong"
is part of the problem.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
___________________________________________________

Posted on the Freebsd-ports mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-ports to subscribe. On Thu, Mar 10, 2011 at 11:43 AM, Ade Lovett <> wrote:
> Work is now underway to bring GNU make 3.82 into the tree.  Sadly, there are a number of rather unfortunate backwards incompatibility issues between this and 3.81 which makes a simple replacement unworkable.
>
> A new port, devel/gmake381 has just been committed to the tree which is a heavily stripped down 3.81 version (just the binary, installed as ${LOCALBASE}/bin/gmake381, no NLS support.   It is also currently marked IGNORE and is NOT attached to devel/Makefile.   Please do NOT use it directly in any way, shape or form.
>
> The next steps are as follows:
>
> 1.  A patchset will be implemented, upgrading devel/gmake to 3.82, attaching devel/gmake381 to the build, and extending the USE_GMAKE variable so that a value of 'yes' will continue to use devel/gmake (now 3.82) and '381' will use the older 3.81
>
> 2.  -exp runs will be iterated over to determine which ports break building with 3.82, and they will be marked as USE_GMAKE=381 to allow them to continue to build.  A list of such ports will be maintained and posted.
>
> 3.  devel/gmake381 will then be marked DEPRECATED with a suitable EXPIRATION_DATE (at least 6 months), at which point it will be removed, and the USE_GMAKE=381 logic also reverted, so that everything will go back to using devel/gmake.  Note: it will not be necessary to edit individual port Makefiles back to USE_GMAKE=yes, since the checks for USE_GMAKE only look to see if the variable is defined.  This will provide for ease of use (grep -R USE_GMAKE=381 ports/) to pick up any stragglers -- not to mention the fact that they'll most likely be broken in weird and interesting ways.
>
> A followup posting will occur as and when steps (1) and (2) have been completed.

You can remove devel/ORBit and irc/xchat-gnome from your patch. I have
fixed those ports to build with gmake 3.82.

Cheers,
Mezz

> -aDe


--
-
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ -
_______________________________________________
___________________________________________________

Posted on the Freebsd-ports mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-ports to subscribe. On Sat, Mar 12, 2011 at 11:48 AM, Jeremy Messenger
<> wrote:
> On Thu, Mar 10, 2011 at 11:43 AM, Ade Lovett <> wrote:
>> Work is now underway to bring GNU make 3.82 into the tree.  Sadly, there are a number of rather unfortunate backwards incompatibility issues between this and 3.81 which makes a simple replacement unworkable.
>>
>> A new port, devel/gmake381 has just been committed to the tree which is a heavily stripped down 3.81 version (just the binary, installed as ${LOCALBASE}/bin/gmake381, no NLS support.   It is also currently marked IGNORE and is NOT attached to devel/Makefile.   Please do NOT use it directly in any way, shape or form.
>>
>> The next steps are as follows:
>>
>> 1.  A patchset will be implemented, upgrading devel/gmake to 3.82, attaching devel/gmake381 to the build, and extending the USE_GMAKE variable so that a value of 'yes' will continue to use devel/gmake (now 3.82) and '381' will use the older 3.81
>>
>> 2.  -exp runs will be iterated over to determine which ports break building with 3.82, and they will be marked as USE_GMAKE=381 to allow them to continue to build.  A list of such ports will be maintained and posted.
>>
>> 3.  devel/gmake381 will then be marked DEPRECATED with a suitable EXPIRATION_DATE (at least 6 months), at which point it will be removed, and the USE_GMAKE=381 logic also reverted, so that everything will go back to using devel/gmake.  Note: it will not be necessary to edit individual port Makefiles back to USE_GMAKE=yes, since the checks for USE_GMAKE only look to see if the variable is defined.  This will provide for ease of use (grep -R USE_GMAKE=381 ports/) to pick up any stragglers -- not to mention the fact that they'll most likely be broken in weird and interesting ways.
>>
>> A followup posting will occur as and when steps (1) and (2) have been completed.
>
> You can remove devel/ORBit and irc/xchat-gnome from your patch. I have
> fixed those ports to build with gmake 3.82.

...and audio/portaudio .

> Cheers,
> Mezz
>
>> -aDe


--
-
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ -
_______________________________________________
___________________________________________________

Posted on the Freebsd-ports mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-ports to subscribe. Jeremy Messenger <> wrote:

> You can remove devel/ORBit and irc/xchat-gnome from your patch. I have
> fixed those ports to build with gmake 3.82.

I fixed net/xtraceroute and deskutils/contacts and sent a patch to
the maintainer of misc/gnustep-examples... since I had those fixes
already lying around from the same issue on a !FreeBSD system.

--
Christian "naddy" Weisgerber

_______________________________________________
___________________________________________________

Posted on the Freebsd-ports mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-ports to subscribe. On Mar 11, 2011, at 23:14 , Doug Barton wrote:
> What harm will come from publicizing this problem and asking for help from the community?

Seems 'the community' has already awoken and started fixing stuff without the second test -exp run even having finished. I rest my case.

-aDe

_______________________________________________
___________________________________________________

Posted on the Freebsd-ports mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-ports to subscribe.

Work is now underway to bring GNU make 3.82 into the tree. Sadly, there are a number of rather unfortunate backwards incompatibility issues between this and 3.81 which makes a simple replacement unworkable.

A new port, devel/gmake381 has just been committed to the tree which is a heavily stripped down 3.81 version (just the binary, installed as ${LOCALBASE}/bin/gmake381, no NLS support. It is also currently marked IGNORE and is NOT attached to devel/Makefile. Please do NOT use it directly in any way, shape or form.

The next steps are as follows:

1. A patchset will be implemented, upgrading devel/gmake to 3.82, attaching devel/gmake381 to the build, and extending the USE_GMAKE variable so that a value of 'yes' will continue to use devel/gmake (now 3.82) and '381' will use the older 3.81

2. -exp runs will be iterated over to determine which ports break building with 3.82, and they will be marked as USE_GMAKE=381 to allow them to continue to build. A list of such ports will be maintained and posted.

3. devel/gmake381 will then be marked DEPRECATED with a suitable EXPIRATION_DATE (at least 6 months), at which point it will be removed, and the USE_GMAKE=381 logic also reverted, so that everything will go back to using devel/gmake. Note: it will not be necessary to edit individual port Makefiles back to USE_GMAKE=yes, since the checks for USE_GMAKE only look to see if the variable is defined. This will provide for ease of use (grep -R USE_GMAKE=381 ports/) to pick up any stragglers -- not to mention the fact that they'll most likely be broken in weird and interesting ways.

A followup posting will occur as and when steps (1) and (2) have been completed.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 09:43, Ade Lovett wrote:
> Work is now underway to bring GNU make 3.82 into the tree. Sadly,
> there are a number of rather unfortunate backwards incompatibility
> issues between this and 3.81 which makes a simple replacement
> unworkable.

Can you give us an idea of how many ports we're talking about? Rather
than having 2 gmake ports (which is likely to last for a very long time,
"best laid plans" aside) can we at least explore the idea of fixing
things that are broken to work with 3.82 first? My suggestion is to do
the -exp run, then post here and to maintainers of broken ports directly
and see what a reasonable time frame would be to get things fixed the
right way first.

My understanding is that there is _currently_ no pressure to get gmake
upgraded, so at least exploring the idea of doing it without a kludge
seems reasonable to me, although I'm happy to be proven wrong.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 13:24 , Doug Barton wrote:
> Can you give us an idea of how many ports we're talking about? Rather than having 2 gmake ports (which is likely to last for a very long time, "best laid plans" aside) can we at least explore the idea of fixing things that are broken to work with 3.82 first? My suggestion is to do the -exp run, then post here and to maintainers of broken ports directly and see what a reasonable time frame would be to get things fixed the right way first.

Preliminary runs show ~50 ports that break with 3.82, some of them unfortunately being dependencies for a reasonable number of others. An -exp has already been run, though there were a number of false positives for whatever reason.

There will absolutely _not_ be two gmake ports for anything more than a suitable deprecation period (if it is determined to move ahead) or for perhaps a month (specifically note that devel/gmake381 is marked IGNORE and not attached to the tree, so anyone trying to use it will have ... problems) if it's too much in the way of hacking.

> My understanding is that there is _currently_ no pressure to get gmake upgraded, so at least exploring the idea of doing it without a kludge seems reasonable to me, although I'm happy to be proven wrong.

The "kludge", in terms of actually testing things to get empirical data, rather than hand-waving about the sky falling, is ~4 lines of code in bsd.port.mk. We have a plan, we're going to get the results of that plan, and then do some analysis on it. Working closely with the pkgsrc tree that already _is_ at gmake-3.82

You may find a more productive approach would be to wander over to the gnumake mailing list, and ask why such a massive amount of backwards incompatibility was introduced in a minor version upgrade. Of course, that's entirely your prerogative. In the meantime, I along with a few others are actually going to _do_ the work involved in _testing_ the _possibility_ of this instead of sitting in our armchairs.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 12:05, Ade Lovett wrote:
>
> On Mar 10, 2011, at 13:24 , Doug Barton wrote:
>> Can you give us an idea of how many ports we're talking about?
>> Rather than having 2 gmake ports (which is likely to last for a
>> very long time, "best laid plans" aside) can we at least explore
>> the idea of fixing things that are broken to work with 3.82 first?
>> My suggestion is to do the -exp run, then post here and to
>> maintainers of broken ports directly and see what a reasonable time
>> frame would be to get things fixed the right way first.
>
> Preliminary runs show ~50 ports that break with 3.82, some of them
> unfortunately being dependencies for a reasonable number of others.
> An -exp has already been run, though there were a number of false
> positives for whatever reason.

What I'm suggesting is that the URL for the logs of that run get posted
here, along with contacting the maintainers of the affected ports. Then
let's see what people have to say about getting them fixed sooner rather
than later. Can you explain why doing that would be a bad idea?

> There will absolutely _not_ be two gmake ports for anything more than
> a suitable deprecation period

I admire your optimism, however experience tells us that once these
types of accomodations get into the tree, they stay there for a long time.

>> My understanding is that there is _currently_ no pressure to get
>> gmake upgraded, so at least exploring the idea of doing it without
>> a kludge seems reasonable to me, although I'm happy to be proven
>> wrong.
>
> The "kludge", in terms of actually testing things to get empirical
> data, rather than hand-waving about the sky falling,

Um, no one said the sky is falling, and you've reacted emotionally to
the term "kludge" rather than answering my question about what the
urgency is to get the update done.

> We have a plan, we're going to get the results
> of that plan, and then do some analysis on it.

And my concern is that the plan seems to have been formulated without
wider input from the community. So I ask again ... what harm can come
from at least trying to fix the broken ports first?


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 14:21 , Doug Barton wrote:
> What I'm suggesting is that the URL for the logs of that run get posted here, along with contacting the maintainers of the affected ports. Then let's see what people have to say about getting them fixed sooner rather than later. Can you explain why doing that would be a bad idea?

Those 50 or so ports are not the complete picture. Some of them are preventing other ports from being built. So, we cycle through an -exp run adding USE_GMAKE=381 (it's not a library or anything, just an executable, and in the context of clean building, only one or the other will exist for a specific port -exp build, so there's no question of interaction) until we have _all_ of the affected ports.

Then the list gets posted somewhere, USE_GMAKE=381 goes active, then there's a period (6-7 months) for folks to clean things up, at which point USE_GMAKE=381 does exactly the same as USE_GMAKE=yes (use gmake-3.82) -- ports that get fixed after this date simply change USE_GMAKE=381 -> USE_GMAKE=yes (cosmetic change only), and a list of known-broken ports can still be determined by grepping for 'USE_GMAKE=381'. If updates to those ports fix them, change USE_GMAKE back to 'yes'.

> I admire your optimism, however experience tells us that once these types of accomodations get into the tree, they stay there for a long time.

There is no issue of optimism about it. gmake-3.82 _will_ be the sole version of GNU make in the tree by (at latest) the end of this year.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 12:52, Ade Lovett wrote:
>
> On Mar 10, 2011, at 14:21 , Doug Barton wrote:
>> What I'm suggesting is that the URL for the logs of that run get
>> posted here, along with contacting the maintainers of the affected
>> ports. Then let's see what people have to say about getting them
>> fixed sooner rather than later. Can you explain why doing that
>> would be a bad idea?
>
> Those 50 or so ports are not the complete picture. Some of them are
> preventing other ports from being built. So, we cycle through an
> -exp run adding USE_GMAKE=381 (it's not a library or anything, just
> an executable, and in the context of clean building, only one or the
> other will exist for a specific port -exp build, so there's no
> question of interaction) until we have _all_ of the affected ports.
>
> Then the list gets posted somewhere,

Great!

> USE_GMAKE=381 goes active,

That's the bit that we disagree on, but your unwillingness to answer the
question I've posed twice now tells me clearly that you are determined
to follow this course of action, so I give up.

>> I admire your optimism, however experience tells us that once these
>> types of accomodations get into the tree, they stay there for a
>> long time.
>
> There is no issue of optimism about it. gmake-3.82 _will_ be the
> sole version of GNU make in the tree by (at latest) the end of this
> year.

You've already slipped your deadline from 6 months firm, to 6-7 months,
now to 9 months in the course of just a few emails. I'd be willing to
wager $BEVERAGE of your choice that we enter 2012 with multiple gmakes
in the ports tree. But like I said, I'd be glad to be proven wrong. :)


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On Thu, Mar 10, 2011 at 02:05:50PM -0600, Ade Lovett wrote:
> Preliminary runs show ~50 ports that break with 3.82, some of them
> unfortunately being dependencies for a reasonable number of others.

For values of "reasonable" in the ~1100 range.

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On Mar 10, 2011, at 14:21 , Doug Barton wrote:
> I admire your optimism, however experience tells us that once these
> types of accomodations get into the tree, they stay there for a long
> time.

Here's what I have on my system:

devel/autoconf
devel/autoconf213
devel/automake
devel/automake14
devel/autotools
devel/libtool

(That's not counting the -wrapper convenience ports.)

So: one antiquated version each of autoconf and automake.

$ dependson autoconf-2.1 | wc -l
73
$ dependson autoconf | wc -l
910
$ dependson automake-1.4 | wc -l
31
$ dependson automake | wc -l
325

('dependson' is just a script that greps INDEX.)

Summary: there used to be a lot of auto* ports. There aren't, now.

Anyone interested in looking through the sordid details can find them at
http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/ .

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

Mark Linimon writes:

> Summary: there used to be a lot of auto* ports. There aren't,
> now.

Am I correct in remembering the "used to be" period covered
2+(+) years?


Robert "sure seemed like it :-)" Huff


_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 15:54, Mark Linimon wrote:
> On Mar 10, 2011, at 14:21 , Doug Barton wrote:
>> I admire your optimism, however experience tells us that once these
>> types of accomodations get into the tree, they stay there for a long
>> time.
>
> Here's what I have on my system:
>
> devel/autoconf
> devel/autoconf213
> devel/automake
> devel/automake14
> devel/autotools
> devel/libtool
>
> (That's not counting the -wrapper convenience ports.)

[snip]

> Summary: there used to be a lot of auto* ports. There aren't, now.

First, my point was not "there are going to be a lot of gmake ports," my
point was, "there will be >1 for a long time after it's split into >1."
You have now proved my point, thanks. While we're discussing anecdotal
evidence:

autoconf-2.13.000227_6
autoconf-2.68

automake-1.4.6_6
automake-1.11.1

But that's only because I periodically do 'pkg_delete auto*' so this is
not really representative.

Meanwhile, this is why I reacted so strongly on IRC when it was
suggested that bifurcating gmake was the way to go. I was 100% certain
at the time that it was a foregone conclusion.

So maybe you will take a stab at my real question, what is the urgency
in upgrading gmake that prevents "fix the broken ports first" as an
option to at least explore? And while we're at it, if you have already
done the iterative -exp runs to get the 1100 ports figure, where are
those logs?


Thanks,

Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 18:09 , Doug Barton wrote:
> First, my point was not "there are going to be a lot of gmake ports," my point was, "there will be >1 for a long time after it's split into >1." You have now proved my point, thanks.

Apples and oranges, my friend. Given the sheer amount of stuff we have in ports/, there is a small amount of stuff that hasn't been updated in forever, nor ever will be, requiring the "legacy" autoconf-2.13/automake-1.4

Go look up pkgsrc. Or any Linux distribution. You'll find both of them lying there. I'd love to nuke them, and those ports that require them to build, but people tend to get upset when Really Important Application (sic) gets removed from under them.

As for the rest of your post. It's the usual diatribe. If you think you can do better, by all means, step up to the plate and actually _do_ something. Like yours truly has done reducing libtool to 1 version, and autoconf/automake to 2 versions (legacy and current).

Unless you're prepared to step up to the plate, offer alternate _concrete_ plans (as I have already done) and are willing to spend considerable brain and cpu cycles to get to the desired solution, you have no right to question what _is_ being done by those that _are_ doing it.

This is _not_ a democracy. The war cry of "Patches Welcome" should be obvious in that fact.

So. Let's see your patches. Seriously. Hell, if someone else takes this on (and note, it is only a matter of time before something fundamental _requires_ GNU make 3.82, so we can't just bury our heads in the sand), go for it.

Didn't think so.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 19:46, Ade Lovett wrote:
>
> On Mar 10, 2011, at 18:09 , Doug Barton wrote:
>> First, my point was not "there are going to be a lot of gmake
>> ports," my point was, "there will be>1 for a long time after it's
>> split into>1." You have now proved my point, thanks.
>
> Apples and oranges, my friend. Given the sheer amount of stuff we
> have in ports/, there is a small amount of stuff that hasn't been
> updated in forever, nor ever will be, requiring the "legacy"
> autoconf-2.13/automake-1.4

And my concern is that we're heading down the same road with gmake.
Maybe it's worth doing that, I don't know. It's hard to make an
intelligent decision when neither you nor Mark will answer what I think
is a totally reasonable question:

What is the urgency in upgrading gmake that prevents "fix the broken
ports first" as an option to at least explore?

> As for the rest of your post. It's the usual diatribe. If you think
> you can do better, by all means, step up to the plate and actually
> _do_ something.

Um, I do quite a bit, thanks. But even if I didn't, it doesn't mean that
I don't get to ask questions.

> Like yours truly has done reducing libtool to 1
> version, and autoconf/automake to 2 versions (legacy and current).

Yes, and that work has been greatly appreciated.

> Unless you're prepared to step up to the plate, offer alternate
> _concrete_ plans (as I have already done) and are willing to spend
> considerable brain and cpu cycles to get to the desired solution, you
> have no right to question what _is_ being done by those that _are_
> doing it.

Yeah, no ... that's not how this works. This is a community, with all
the problems that entails. Work on something this important should not
be happening in a vacuum. At bare minimum it's impossible to provide an
intelligent answer to the question of, "Is there a better way to do it?"
because we (the community) don't have all the facts. So what I'm asking
for as step 1 is, share the facts. Then step 2 _should be_, work
together to find the right solution. If it turns out that your idea is
actually the best one, then great, let's do it! OTOH, throwing the door
open and having the many smart people who are interested in making
FreeBSD ports better have a crack at it might just result in a
better/easier solution. It might even result in getting more volunteers
who have the desire and ability to actually help with the work. I don't
see a downside here. But if you'd like to engage in a discussion rather
than throwing around ad hominem's and pointless "patches welcome"
statements, maybe you can show me why I'm wrong.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
I answered this question last night on IRC, aDe answered it in email:

> What is the urgency in upgrading gmake that prevents "fix the broken
> ports first" as an option to at least explore?

Now that gmake is out, if the past is any indication, some project
will quickly upgrade to it. We can wait for that to happen, and then
have to scramble, or we can get ahead of the curve.

Not every single change to the Ports Collection rises to the level of
requiring a committee meeting to generate a consensus. IMHO this does
not. In this case it was "here is someone willing to do the work, here's
an action plan, let's just do it."

I've already spent nearly as much time arguing with you as I had spent
running the initial -exp run (more, if you exclude the work I did to
update the processonelog script), so I'm done here.

mcl
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)

On Mar 10, 2011, at 22:02 , Doug Barton wrote:
> But if you'd like to engage in a discussion rather than throwing around ad hominem's and pointless "patches welcome" statements, maybe you can show me why I'm wrong.

How about working from the basis that perhaps, just perhaps, I'm _right_, and show me why _I_ am wrong. After all, right now, I see me and a few others doing actual _work_, and others merely taking potshots.

By all means, show an alternate solution, one that assumes that some project or another, which will be a part of the FreeBSD ports collection, will _require_ GNU make 3.82, and we can go from there.

Believe me, I'm willing to listen to well thought on, start to end, include all possibility plans, but right now, all I'm seeing is "you're wrong" without anything substantial to back it up so, at this point, I'd like to focus on the issue at hand and get the work _done_.

-aDe

_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-"
)
On 03/10/2011 21:05, Mark Linimon wrote:
> I answered this question last night on IRC, aDe answered it in email:
>
>> What is the urgency in upgrading gmake that prevents "fix the broken
>> ports first" as an option to at least explore?
>
> Now that gmake is out, if the past is any indication, some project
> will quickly upgrade to it. We can wait for that to happen, and then
> have to scramble, or we can get ahead of the curve.

I can see why that would make it an important problem, but I don't see
why that makes the problem so urgent that sharing it with the community
and asking them for suggestions can't be done first; especially
considering that there is at least one workable plan in the wings if no
one comes up with something better.

> Not every single change to the Ports Collection rises to the level of
> requiring a committee meeting to generate a consensus. IMHO this does
> not.

It's really, really frustrating to me when I spend time trying to make
myself clear and you consistently mischaracterize it. I can't tell if
you're doing it on purpose, I'm failing to communicate, or something
else is going on. But just to be clear, I'm not talking about making a
committee decision. I'm talking about making the information about the
problem available to the community.

> In this case it was "here is someone willing to do the work, here's
> an action plan, let's just do it."

And while that sounds noble and all, it's the wrong road to go down.
There are way too many things happening "in private" around here and the
only way to solve that problem is to open the doors.

Meanwhile, while I appreciate you answering one of my questions, but you
still haven't answered arguably the more important one.

What harm will come from publicizing this problem and asking for help
from the community?

On 03/10/2011 21:25, Ade Lovett wrote:

> How about working from the basis that perhaps, just perhaps, I'm
> _right_, and show me why _I_ am wrong.

I can't help thinking that the fact that when I say, "Let's ask the
community for input on this topic" you _hear_ me saying, "You're wrong"
is part of the problem.


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

_______________________________________________
___________________________________________________

Posted on the Freebsd-ports mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-ports to subscribe. On Thu, Mar 10, 2011 at 11:43 AM, Ade Lovett <> wrote:
> Work is now underway to bring GNU make 3.82 into the tree.  Sadly, there are a number of rather unfortunate backwards incompatibility issues between this and 3.81 which makes a simple replacement unworkable.
>
> A new port, devel/gmake381 has just been committed to the tree which is a heavily stripped down 3.81 version (just the binary, installed as ${LOCALBASE}/bin/gmake381, no NLS support.   It is also currently marked IGNORE and is NOT attached to devel/Makefile.   Please do NOT use it directly in any way, shape or form.
>
> The next steps are as follows:
>
> 1.  A patchset will be implemented, upgrading devel/gmake to 3.82, attaching devel/gmake381 to the build, and extending the USE_GMAKE variable so that a value of 'yes' will continue to use devel/gmake (now 3.82) and '381' will use the older 3.81
>
> 2.  -exp runs will be iterated over to determine which ports break building with 3.82, and they will be marked as USE_GMAKE=381 to allow them to continue to build.  A list of such ports will be maintained and posted.
>
> 3.  devel/gmake381 will then be marked DEPRECATED with a suitable EXPIRATION_DATE (at least 6 months), at which point it will be removed, and the USE_GMAKE=381 logic also reverted, so that everything will go back to using devel/gmake.  Note: it will not be necessary to edit individual port Makefiles back to USE_GMAKE=yes, since the checks for USE_GMAKE only look to see if the variable is defined.  This will provide for ease of use (grep -R USE_GMAKE=381 ports/) to pick up any stragglers -- not to mention the fact that they'll most likely be broken in weird and interesting ways.
>
> A followup posting will occur as and when steps (1) and (2) have been completed.

You can remove devel/ORBit and irc/xchat-gnome from your patch. I have
fixed those ports to build with gmake 3.82.

Cheers,
Mezz

> -aDe


--
-
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ -
_______________________________________________
___________________________________________________

Posted on the Freebsd-ports mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-ports to subscribe. On Sat, Mar 12, 2011 at 11:48 AM, Jeremy Messenger
<> wrote:
> On Thu, Mar 10, 2011 at 11:43 AM, Ade Lovett <> wrote:
>> Work is now underway to bring GNU make 3.82 into the tree.  Sadly, there are a number of rather unfortunate backwards incompatibility issues between this and 3.81 which makes a simple replacement unworkable.
>>
>> A new port, devel/gmake381 has just been committed to the tree which is a heavily stripped down 3.81 version (just the binary, installed as ${LOCALBASE}/bin/gmake381, no NLS support.   It is also currently marked IGNORE and is NOT attached to devel/Makefile.   Please do NOT use it directly in any way, shape or form.
>>
>> The next steps are as follows:
>>
>> 1.  A patchset will be implemented, upgrading devel/gmake to 3.82, attaching devel/gmake381 to the build, and extending the USE_GMAKE variable so that a value of 'yes' will continue to use devel/gmake (now 3.82) and '381' will use the older 3.81
>>
>> 2.  -exp runs will be iterated over to determine which ports break building with 3.82, and they will be marked as USE_GMAKE=381 to allow them to continue to build.  A list of such ports will be maintained and posted.
>>
>> 3.  devel/gmake381 will then be marked DEPRECATED with a suitable EXPIRATION_DATE (at least 6 months), at which point it will be removed, and the USE_GMAKE=381 logic also reverted, so that everything will go back to using devel/gmake.  Note: it will not be necessary to edit individual port Makefiles back to USE_GMAKE=yes, since the checks for USE_GMAKE only look to see if the variable is defined.  This will provide for ease of use (grep -R USE_GMAKE=381 ports/) to pick up any stragglers -- not to mention the fact that they'll most likely be broken in weird and interesting ways.
>>
>> A followup posting will occur as and when steps (1) and (2) have been completed.
>
> You can remove devel/ORBit and irc/xchat-gnome from your patch. I have
> fixed those ports to build with gmake 3.82.

...and audio/portaudio .

> Cheers,
> Mezz
>
>> -aDe


--
-
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ -
_______________________________________________
___________________________________________________

Posted on the Freebsd-ports mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-ports to subscribe. Jeremy Messenger <> wrote:

> You can remove devel/ORBit and irc/xchat-gnome from your patch. I have
> fixed those ports to build with gmake 3.82.

I fixed net/xtraceroute and deskutils/contacts and sent a patch to
the maintainer of misc/gnustep-examples... since I had those fixes
already lying around from the same issue on a !FreeBSD system.

--
Christian "naddy" Weisgerber

_______________________________________________
___________________________________________________

Posted on the Freebsd-ports mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-ports to subscribe. On Mar 11, 2011, at 23:14 , Doug Barton wrote:
> What harm will come from publicizing this problem and asking for help from the community?

Seems 'the community' has already awoken and started fixing stuff without the second test -exp run even having finished. I rest my case.

-aDe

_______________________________________________
___________________________________________________

Posted on the Freebsd-ports mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-ports to subscribe. On Fri, Mar 11, 2011 at 09:14:50PM -0800, Doug Barton wrote:
> There are way too many things happening "in private" around here and
> the only way to solve that problem is to open the doors.

Would you please offer examples of decisions that you feel that way about?

mcl
_______________________________________________
___________________________________________________

Posted on the Freebsd-ports mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-ports to subscribe.