ASSP out of date

[Scott Haneda]

On Nov 11, 2008, at 3:10 AM, Ryan Schmidt wrote:

> On Nov 11, 2008, at 03:57, Bryan Blackburn wrote:
>
>> On Tue, Nov 11, 2008 at 01:20:51AM -0800, Scott Haneda said:
>>
>>> 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...
>
> Yes, but his port says "use_configure no" but then also has  
> "configure {...}" (with actual code in place of "..."). In this  
> case, since you did write a configure phase, you should not say  
> "use_configure no".

That is how I felt as well, a few million emails ago, someone  
mentioned to add it, and I thought it was odd, but did just so I could  
move on.  I should have asked for clarification.

>>> 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.
>
> Right. But it can be clearer to put them in order in the Portfile,  
> too.
>
>
>
> Other comments on your portfile:
>
> Near the top you still define:
>
> set assp_base           ${prefix}/var/assp
>
> And you use this in reinplace:
>
> reinplace "s%/usr/local/assp%${assp_base}%" ${worksrcpath}/$file
>
> However in the destroot you deal with ${prefix}/var/ASSP:
>
> file delete -force "${prefix}/var/ASSP"
>
> Which case is correct? You must use the correct case, for the  
> benefit of users running on case-sensitive filesystems. In the  
> destroot, you should probably reuse the assp_base variable again.

Yes, I knew that would bite me, I at the very last minute before  
posting this, changed to ASSP, since that is how the distro is now,  
whereas it was assp in the distro zip in the past.

I had intentions of cleaning up the case at a later time, since I  
figure, there are at least a few who run case sensitive on OS X, and I  
am sure many more on non OS X that do so by default.

> Also, to this question:
>
>>> I am a little confused on the ideal way to use pre-patch,  
>>> configure, build, and destroot.
>>>
>>> Taking a cue from the original port, I put the first reinplace, to  
>>> delete DOS endings in pre-patch, this makes sense to me to be here.
>
> The change to the line endings was done before the patch phase,  
> because in the patch phase, those files needed to be patched, but  
> the patchfiles themselves used UNIX line endings. The files to be  
> patched needed to be changed to have the same line endings as the  
> patchfile.
>
> The patchfile could have been stored with DOS line endings, but that  
> would be weird on Mac OS X, and someone's editor might screw it up  
> when changing it in the future. Also not sure how the UNIX command- 
> line diff utilities fare with DOS line endings. Better to use UNIX  
> line endings; we're sure how that works.
>
> Since your new portfile doesn't do any patching, you may not need to  
> muck with the line ending of these files anymore. Not sure.

I am torn on this issue.  The original port maintainer used it, but  
there is no contact address I can see.  I can not ask, so I am  
assuming he discovered some other reason why those line endings were  
needed to be changed.  I would like to delete that part, but ahhhh...  
what the hell, I will remove it, and simply test that all works out ok.

It was good, I learned fs-traverse as well as a lot of other tcl stuff  
working on just that one issue.

>>> I then put the reinplace of the perl path, as well as the /usr/ 
>>> local/assp path replacement in configure.  Is this correct?  To  
>>> me, it seems a pre-patch thing.  I fail to locate docs that tell  
>>> me what is most ideal for each action.
>
>
> Yeah, it might make sense to do that in the patch phase too. And  
> then to not have a configure phase (by using "use_configure no"). It  
> probably doesn't make a lot of difference here though.


I think more stuff in a logical place, which is more clear to someone  
else, so I will take this direction.

Thank you.
--
Scott