Hi all, so we took this off list for a bit to work out an implementation.
On 3/29/2012 10:46, Matthew Seaman wrote: > On 28/03/2012 22:04, Mel Flynn wrote: >> I'm not sure about exclusion. I have an implementation up here: >> http://redports.org/browser/melflynn/net-mgmt/observium/bsd.www.mk >> >> The problem with -not -path $glob is that it isn't the inverse of inclusion: >> PORTWWW= html >> will only find the dir html and everything below it. >> PORTWWWEXCLUDE= html >> will only exclude the html dir but not everything below it. The correct >> way to write this would be: >> PORTWWWEXCLUDE= html html/* >> >> I also can't see a way to do this, since: >> html/* - won't match the file named html and we can't test for -d/-f >> html* - will also match the paths html.php and htmladmin which may be >> undesired. >> >> I suppose one can document it to not abuse the exclusion for directories >> but strictly for files. > > Hmmm... yes. The '-not -path "/foo/bar"' construction (not using > wildcards) really only works with files. To stop find(1) recursing into > a whole directory subtree by naming the top of that subtree you'ld use > -prune. With wildcards, yes, it is different, . Since -prune is always true, it's a whole different beast that requires wrapping any other arguments into -o \( ... -print \). It won't work well here. > There is some precedence for using separate variables for files vs > directories: see PLIST_DIRS, PLIST_DIRSTRY and PLIST_FILES. If we separate exclusion into files and dirs, things get a lot easier, as we can simply use -not -path '${WWWDIR}/${glob}' -not -path '${WWWDIR}/${glob}/*' for a directory. The only question is whether to use PORTWWWEXCLUDE_FILES explicitly or have PORTWWWEXCLUDE be the files one. > There's also the @dirrm vs @dirrmtry question. Yes, I thought about that. I think it can be done with some post-processing, rewriting @dirrm foo to @dirrmtry foo for dirs matching PORTWWW_DIRSTRY. > Anyhow, would you consider publishing your work on freebsd-ports@... so > more interested parties can comment on it? I think it has promise and > I'll have a go trying to apply it to some of my ports over the next week > or so. If it can work correctly with www/rt40 then it should work for > anything. I'll have these changes incorporated later tonight. While there's now a lot of variables to consider, it's hard to loose sight of the fact that the common case will only use PORTWWW=* + the exclusion of one or two configuration files. -- Mel _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"