ASSP out of date
Scott Haneda
talklists at newgeo.com
Fri Nov 7 18:49:09 PST 2008
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
More information about the macports-users
mailing list