ASSP out of date

[Bryan Blackburn]

On Tue, Nov 11, 2008 at 01:20:51AM -0800, Scott Haneda said:
> Hello, had some more spare time this evening, working on the assp port, 
> thanks to all who are entertaining me in this training process.
>
> I am working on the port as it started, so I issue sudo port edit assp.
> If I run:
> clear; sudo port -d install assp
> I generally get a bunch of errors, certainly a lot less if I uninstall  
> the port first.  In the interest of learning, can someone explain what is 
> going on, here is the output:
> http://pastebin.com/m61fea40e
> ( I have a good deal of ui_info " MY DEBUG: *" in there )

The basic problem is that you're trying to install stuff directly, but
everything needs initially to be underneath ${destroot} so port can then
figure out what files belong to the software.  Your destroot phase should
get rid of the 'file delete ...' and change the copy to be

   file copy "${worksrcpath}" "${destroot}${prefix}/var/ASSP"

[...]
>
> Since this is just moving files around, I have set
> use_configure		no
> but that seems misleading to me, if it is set to no, how come configure 
> still gets run?

Since ASSP doesn't have a configure script, if it were being run you'd see
an error message about it; I'm guessing you're talking about the line

   DEBUG: Executing org.macports.configure (assp)

which is a bit misleading because once it does that, it does nothing else...

>
> pre-patch, configrue, build, and destroot all appear to be what I would 
> call tcl functions, does the order of placement in the port file make any 
> difference at all, or are the parsed and ran in the order they need to be? 
>  I think the logical order would be

Order in the Portfile doesn't matter for those, they are run in the logical
order (fetch, extract, patch, configure, build, destroot, install, activate)
with pre- and post- phases for each available.

[...]
>
> Thanks, once this works, I will work on the destroot and making sure it 
> does not nuke config and bayes database and other files, that should leave 
> me with figuring out what perl modules need ports.

Note that during development of a port, it's best to initially run through
the destroot phase, and if at all possible, as a user who can't write to the
MacPorts install location.  Eg,

$ port -d destroot

in the Portfile directory, as you, this way if your uid doesn't have write
access, it will fail to write things directly to ${prefix} so you know
there's something that needs to be updated so it goes into
${destroot}${prefix} instead.

Bryan


> --
> Scott
>