ASSP out of date

[Scott Haneda]

Any chance someone can take a poke at this one? I'm trying to have a  
running port by wekkends end.

I know there is a lot in there but I'm stumped.

Thanks.

--
Scott
Iphone says hello.

On Nov 7, 2008, at 6:49 PM, Scott Haneda <talklists at newgeo.com> wrote:

> Is there a long standing debate on this list that a normal reply  
> does not go back to the list?  I am sorry to all of you who I have  
> replied to direct, I did intend for it to go to the list for the  
> benefit of the archives.
>
> On Nov 6, 2008, at 1:06 AM, Bryan Blackburn wrote:
>> What goes in there of course depends on how you actually install  
>> this port;
>> since you've done this by hand you should have a pretty good idea.   
>> Though
>> note everything should go into things starting with ${destroot}$ 
>> {prefix} as
>> that is a staging area, so port can then scan it to find all files to
>> install.
>>
>> For a manual install, see as an example the destroot phase of
>>
>> <http://trac.macports.org/browser/trunk/dports/math/ent/Portfile>
>>
>> to at least get you started.  If you have to install a number of  
>> files
>> matching various patterns, see the last part of the post-destroot  
>> phase in
>>
>> <http://trac.macports.org/browser/trunk/dports/archivers/lzo2/Portfile 
>> >
>>
>> which uses glob to match multiple files.
>
>
> Yes, these are just files, which is the part in the script that I am  
> at now.
>
> First, there is the issue of needing to do things to the files while  
> they are freshly unpacked.  I am yet to find a good way to  
> recursively act on a set of files in TCL.
>
> The idea is, I have a set of files, and directories, and who knows  
> how deep they go, or what the developer will do to the arrangement  
> later.
>
> Sure, I can do the foreach file1 file2 file3 dir1/file1 dir1/file2  
> with a glob, but that is then something I have to maintain.  I can  
> stuff the files and directories into a list, which makes it a little  
> easier...
>
> At the end of the day, I think it would be best to simply say, "I  
> want to perform an action on all files below 'directory', using a  
> file extension filter.
>
> It can be a whitelist, or a blacklist, that is trivial, though a non  
> extension file may have to have some though put into it.
>
> How does one do this in tcl?  I have a test case, and this is my  
> first ever step into tcl, and further, my first recursive function  
> that deals with recursion.  Never called the function itself in a  
> function before...
>
> proc recursiveDirList { dir } {
>    set tmp_list {}
>    # Traverse top directory
>    set contents [glob -nocomplain -directory $dir *]
>    foreach item $contents {
>        lappend tmp_list $item
>        # Recurse - go into the sub directory
>        if { [file isdirectory $item] } {
>            lappend tmp_list [recursiveDirList $item]
>        }
>    }
>    # Final result, a list of all files and directories in $dir
>    return $tmp_list
> }
>
>
> # Iterate the results,
> foreach line [recursiveDirList $worksrcpath] {
>   if { [regexp {((.*\.txt)|(.*\.dat)|(.*\.pl)|(.*\.sh))} $line] } {
>       puts "-"
>       puts $line
>       puts "-"
>   }
> }
>
> So the first one just makes a list of all directories and files.   
> First bad thing is that I do not want the directory in there, there  
> is no action I will ever take on a directory.  Second, when I print  
> out the list, it is not a clean list, but a nested one, and some  
> items have "{" and "}" wrapping the path items, which makes no sense  
> to me. Stumped.
>
> I then made the second chunk of code, in order to filter the files I  
> want. I suspect there is a better regex I can use to make sure it  
> ends with, and does not contain the pattern, and it should be case  
> insensitive.
>
> In reality, it would be much more ideal to simply supply a file  
> extension list to the first function, and return a nice clean list  
> of the files.
>
> I gave up on this, and did it in a less future proof way, for the  
> sake of having less code in the port.  If someone can help me with  
> this to make it worthwhile, I would rather go this route.  It would  
> be an nice way to remove DOS lines endings, or do basic find and  
> replace across a bunch of files.  I never have to worry if the  
> developer changes things.
>
> -------
> How does one decide where to put the final set of files?  Currently,  
> it looks like the old assp puts it in /opt/local/var but how was  
> that decided?  Do I hard code that path, or is there a built in I am  
> missing?
>
> The old assp port file did some user and group adding, and I have  
> never done that in the past to make this run. Is this a requirement  
> to do so, or at least a good practice?  I will check with the  
> developer, but I think the permissions are best set to the user that  
> installed it.  Or in the OS X case, the logged in user I would  
> assume. I can not see why this set of files needs to run as anything  
> else, it has it's own http server, so permissions and user/group, as  
> long as the same as the http server, would be fine.
>
> In the old assp port I also see basically, once line of xinstall for  
> every file that needs dealing with.  Is there not a way to simply  
> tell it to take a directory, and move it where it needs to go?  if  
> not, what about the subdirectories, I have to move the individual  
> files one at a time, and then how do I create those files parent  
> directory?
>
> Finally, after all that, I will get to the dependencies, for which,  
> about 25% of them do not seem to have port files.  From looking over  
> many of the p5-* ports, is it really as simple as that, sort of like  
> CPAN does it, MacPorts does that as well, so I simply make this bare  
> minimum port file, and it runs with it? What happens if this newly  
> made port file has dependencies, and those dependencies have  
> dependencies?  Do I have to traverse the entire dependency tree to  
> get them to work?  I could be in those for 20 or so port files if  
> that is true :)
>
> Thanks again.
> --
> Scott