PORTWWW proposal (Was: Re: How useful is %%DATADIR%%, anyway?)

[Mel Flynn]

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 at ... 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