portfile and install scripts

[Ryan Schmidt]

On Sep 11, 2009, at 20:19, Jack Howarth wrote:

>   I am switching all of my packaging efforts over
> from fink to MacPorts

Welcome! We're glad to have you on board.


> and had a question which I
> haven't quite found the answer to in the MacPorts
> documentation. My initial attempt was going to be
> a port of the molmol molecular modelling program.
> The fink packaging script uses an InstallScript
> of the form...
>
> InstallScript: <<
> #!/bin/zsh -efv
> /bin/rm -f **/*.o **/*.c
> mkdir -p %i/share/molmol
> cp -R * %i/share/molmol/.
> mkdir -p %i/bin
> ln -s %p/share/molmol/molmol %i/bin/molmol
> mkdir -p %i/share/doc/molmol
> ln -s %p/share/molmol/COPYING  %i/share/doc/molmol/COPYING
> ln -s %p/share/molmol/man  %i/share/doc/molmol/man
> <<

Ok, looks like a shell script with some variable substitution.  
MacPorts portfiles have (more verbosely-named) variables for the same  
kinds of things, but portfiles are Tcl scripts, not shell scripts.

We have some extensions to Tcl in MacPorts that let you write some  
commands that look like shell commands. For example, we have "ln -s"  
in MacPorts and you can use it as if you were in a shell script. But  
it's really just an alias for the Tcl procedure "file link -symbolic".  
We also have "xinstall" which behaves a lot like the shell command  
"install" and is what is usually used in portfiles to install files  
and directories. Consult the guide at http://guide.macports.org/ and  
any Tcl reference to see what other syntax is available.


> What is best practices in MacPorts for trying to achieve
> this. Would that be achieved with a single phase override
> like...

If the software in question has no "make install", or the "make  
install" is too broken to make it worthwhile to fix, then yes, you can  
override the destroot phase.

If "make install" exists and works, or can be patched without too much  
effort to work, then that's preferred. If you need to do additional  
work beyond what "make install" does, you can do so in a post-destroot  
phase.


> destroot {
> /bin/rm -f **/*.o **/*.c

Not valid in Tcl. Look into the "file delete" and "glob" functions.

> mkdir -p ${destroot}${prefix}/share/molmol

Use "file mkdir" or "xinstall -d" when you want to make a directory.  
My own stylistic preference is to use "xinstall" in the destroot phase  
and "file" in other phases.

But in this case, skip the creation of this directory, because you can  
more easily just copy the whole worksrcpath:

> cp -R * ${destroot}${prefix}/share/molmol/.

file copy ${worksrcpath} ${destroot}${prefix}/share/molmol/

> mkdir -p ${destroot}${prefix}/bin

Not necessary; MacPorts makes this directory for you.

> ln -s ${prefix}/share/molmol/molmol ${destroot}${prefix}/bin/molmol
> mkdir -p ${destroot}${prefix}/share/doc/molmol

xinstall -d

> ln -s ${prefix}/share/molmol/COPYING  ${destroot}${prefix}/share/doc/ 
> molmol/COPYING
> ln -s ${prefix}/share/molmol/man  ${destroot}${prefix}/share/doc/ 
> molmol/man
> }

I'm not sure it makes sense to symlink the manpages into the doc  
directory. Manpages should be in the share/man directory so that the  
man command can find them. Speaking of which, would the man command  
find manpages in ${prefix}/share/molmol/man? I wouldn't think so, so I  
would suggest moving the manpages from wherever they get installed to $ 
{prefix}/share/man/manX where X is the correct category number. Or if  
the configure script (if there is one) has a --mandir parameter or  
other way you can influence where manpages go, use that instead of  
moving it later.