patching in general

[Ryan Schmidt]

On Feb 5, 2009, at 08:11, Bradley Giesbrecht wrote:

>>> I really don't mind patching, I'm kinda used to it on osx  
>>> although I do not claim to be an expert, but it would be nice if  
>>> there was a macports best practice or something so if a person  
>>> takes the time to add a some functionality there is the best  
>>> chance that it will be acceptable to the maintainer.
>>
>> Best practice specifically for linking a port with MacPorts  
>> mysql5? Or were you looking for something more general?
>
> In general.
>
>>> For instance, some guidance on reinplace vs patch files. Use of  
>>> symlinks vs patching configure.
>>
>> I say use a patchfile when possible, so that if and when the  
>> upstream source changes and your patch breaks, you'll have the  
>> context of the patchfile to know whether you need to update or  
>> remove the patchfile. Use reinplace to replace things like $ 
>> {prefix} and ${x11prefix} and other variables that can be  
>> different on different users' systems, but ideally first have a  
>> patchfile that changes the prefix to "@PREFIX@", then use  
>> reinplace to change "@PREFIX@" to "${prefix}".
>
> This is the type of guidance I was thinking of.
>
> Preferred method for fixing paths.
> 	1. Patch files with "@PREFIX@" or "@X11PREFIX@" and use reinplace  
> "${prefix}" or "${x11prefix}".

1. Do nothing, because MacPorts already puts "--prefix=${prefix}" in  
configure.pre_args and most software uses configure scripts and most  
configure scripts understand that flag.
2. If there is another flag you need to use instead, overwrite  
configure.pre_args.
3. If there is no flag to do this, try an environment variable.  
("configure.env-append PREFIX=${prefix}").
4. If no environment variable exists for this, then patch.


To this I would add:

Preferred method for getting software to install into the destroot.
1. Do nothing, because MacPorts already puts DESTROOT=${destroot}$ 
{prefix} into destroot.destdir and most Makefiles support this.
2. If there is another variable you need to use, overwrite  
destroot.destdir (perhaps "destroot.destdir INSTALL_ROOT=${destroot}$ 
{prefix}" or "destroot.destdir PREFIX=${destroot}${prefix}").
3. If the Makefile doesn't support DESTROOT, request from the author  
that they do. If they won't or you can't wait for their fix, patch  
the Makefile to support DESTROOT, or override the destroot phase  
entirely and xinstall the files into place in the portfile.
4. Sometimes in post-destroot you have to "reinplace s|${destroot}||  
somefiles" because the destroot path has gotten inserted into them.


> Preferred method for fixing libs and includes.
> 	1. Check if configure.ldflags-append and configure.cppflags-append  
> will work.
> 	2. Patch file.

1. Do nothing, as MacPorts already puts -L${prefix}/lib in  
configure.ldflags and -I${prefix}/include in configure.cflags so that  
most MacPorts software should be automatically found.
2. If not, look for a --with-foo=path configure option, such that you  
could for example "configure.args-append --with-zlib=${prefix}".
3. Sometimes software responds to specific environment variables,  
e.g. for graphviz you could "configure.env-append FONTCONFIG_CFLAGS=-I 
${prefix}/include FONTCONFIG_LIBS=-L${prefix}/lib".
4. You could add nonstandard library paths to the CPPFLAGS and  
LDFLAGS globally with "configure.cppflags-append -I${prefix}/include/ 
something" and "configure.ldflags-append -L${prefix}/include/something".
5. If there's really no other way, patch.


> Preferred method for removing incompatible flags.
> 	1. Example mysql, -lcrypt. reinplace " -lcrypt"

I wouldn't have made a separate section on removing incompatible  
flags, as for me it just falls under patching. I would not use  
reinplace to remove a flag like -lcrypt; I would use a patchfile so  
that if upstream ever fixes their software to not use -lcrypt and  
your patch then breaks, you'll be able to tell why.

-lcrypt specifically is a flag you find in some Linux software but  
which is incompatible with and unnecessary on Mac OS X. If software  
tries to use that flag on Mac OS X, you would write a patchfile to  
remove that option, but only apply the patchfile on platform darwin.  
(MacPorts could be installed on a non-Mac operating system and you  
wouldn't want this particular patch to be applied there.) Ideally you  
would report the problem to the author of the software and they would  
fix their configure script or whatever, so that Mac users who are not  
using MacPorts will also benefit from what we discovered and we can  
remove our patch with the next release. Sometimes software authors  
have no interest in making such changes to their software (whois).  
That's their prerogative. In that case, we maintain the patchfile in  
MacPorts forever.


> It's important for me to thank you and the entire macports  
> community for your work. I may be getting behind on my projects by  
> trying to use and contribute to macports but I wouldn't even be  
> attempting to do this on a mac if projects like macports didn't  
> exist. And I am so happy to be typing this on my Macbook running  
> Leopard rather then a FreeBsd desktop or always needing a remote  
> shell.

It is nice that there is a single place (MacPorts) where you can go  
for all your software compilation needs, where someone else has  
already done (a lot of) the work of getting stuff to compile right on  
the Mac. Sometimes it's straightforward to do it by hand but  
sometimes it's not, and it's good that not everyone has to figure  
that out for themselves. I'm glad you've found MacPorts to be useful.