Bug 94526

Comment 1 Edwin Groothuis 2006-03-16 15:24:34 UTC

Responsible Changed
From-To: freebsd-ports-bugs->ade

Over to maintainer

Hello,
	I am using the patch available from http://savannah.gnu.org/bugs/? 
func=detailitem&item_id=15182 for bug #15182 in gnu make. You could  
apply it to the stable version of make without introducing  
incompatibilities. Attached is my patch to devel/gmake port

In Message-ID: <FBF7CC75-58DB-4865-A06D-E572C3E8DE17@gmail.com> 
Robert Muir <rcmuir@gmail.com> wrote:

> 	I am using the patch available from http://savannah.gnu.org/bugs/? 
> func=detailitem&item_id=15182 for bug #15182 in gnu make. You could  
> apply it to the stable version of make without introducing  
> incompatibilities. Attached is my patch to devel/gmake port

Many thanks for your patch!
your attached patch is just introducing hash instead of directly
in the memory so introducing incompatibilities.
It seems to be a good patch and we don't need gmake-devel.

So Ade, could you please approve to commit Robert Miur's patch?
I coluld build gcc+libjava as Robert and others.

thanks!
-- NAKATA, Maho (maho@FreeBSD.org)

by the way, this is the patch I am using against gcc41 port. I  
believe it is incomplete though, and needs a line added to the  
makefile like BUILD_DEPENDS or something so the system does not let  
someone attempt to build gcc41 port with an outdated make.

with both these patches, I am able to build and install gcc41 with  
java on a machine with 128MB ram and using ulimit -v256000

Comment 5 Ade Lovett 2006-03-23 07:21:35 UTC

Unfortunately, this patch falls foul of two guidelines.

1.  We've deprecated the patch-XY naming convention
2.  There is a strict requirement of one file per patch file, as  
opposed to the multitude of files that are getting patched within  
this single 'patch-ac'

If that can be addressed, once 5.5/6.1 are out of the door, we can  
arrange to have an -exp run done with these changes to verify that it  
doesn't break any other ports.

-aDe

OK I can fix these, but I have attached some comments that might be  
helpful.

On Mar 23, 2006, at 2:21 AM, Ade Lovett wrote:

> Unfortunately, this patch falls foul of two guidelines.
>
> 1.  We've deprecated the patch-XY naming convention

Just FYI: The reason I submitted as patch-ac is because there was a  
patch-ab.  If you want good patch submissions from people, then  
things like that will need to be fixed. Any developer I know is going  
to try to stick with the naming conventions/style guidelines within  
the file/directory he or she is working on when working on an  
unfamiliar codebase.

> 2.  There is a strict requirement of one file per patch file, as  
> opposed to the multitude of files that are getting patched within  
> this single 'patch-ac'

The only reason I did it as one big patch is because thats the way it  
was posted to the GNU Make bug report.  This is already version #2 of  
the patch posted to that bug report.  Although I doubt there will be  
a version #3, I kept the patch as-is in case it was updated again,  
this would make maintenance of the port easier.

>
> If that can be addressed, once 5.5/6.1 are out of the door, we can  
> arrange to have an -exp run done with these changes to verify that  
> it doesn't break any other ports.
>
> -aDe
>

-- 
Robert Muir
rcmuir@gmail.com

Comment 7 Ade Lovett 2006-03-24 04:20:20 UTC

On Mar 23, 2006, at 05:32 , Robert Muir wrote:

> OK I can fix these, but I have attached some comments that might be  
> helpful.

These are both covered in the Porters Handbook, Section 4.4:

http://www.freebsd.org/doc/en/books/porters-handbook/slow-patch.html

Paragraphs 1 and 2 respectively.

-aDe

Hello ade,
a patch for gmake has been submitted. Could you please invesitvate this?
patch is merely using hash rather than directly using malloc.
I think it is safe...and we don't need devel/gmake-devel any more.
thanks,
-- NAKATA, Maho (maho@FreeBSD.org)

Comment 9 Ade Lovett 2006-03-29 07:35:23 UTC

On Mar 27, 2006, at 14:03 , NAKATA Maho wrote:

> Hello ade,
> a patch for gmake has been submitted. Could you please invesitvate  
> this?
> patch is merely using hash rather than directly using malloc.
> I think it is safe...and we don't need devel/gmake-devel any more.

I'm waiting for an updated version of the patch that conforms to the  
guidelines laid out in the Porters Handbook.  Once that's been taken  
care of, it will get scheduled for an -exp build run at some  
convenient time.

-aDe

aDe:

> I'm waiting for an updated version of the patch that conforms to the  
> guidelines laid out in the Porters Handbook.  Once that's been taken  
> care of, it will get scheduled for an -exp build run at some  
> convenient time.

Thanks for your reply. I reviwed gmake.diff by Robert Muir again
but I don't see a problem(it does bump portrevision correctly and
merely adding patches). Could you please where is the point which
violate the guidebook?

All the best,
-- NAKATA, Maho (maho@FreeBSD.org)

Comment 11 Ade Lovett 2006-06-27 21:04:50 UTC

State Changed
From-To: open->closed

devel/gmake has been updated to 3.81, so no need for this repocopy.