Hi,
> 
>  Ok, I understand, the /tmp partition is essentially too small.
>    
In a sense yes, and in many cases it's a big problem to resize the damn 
thing :-/...and regardless, bigger just means that people get even 
sloppier ;-)

> 
>  This is already possible with --tmpdir, so I assume what you are
>  asking for is that PerlApp should try to create this directory
>  if it doesn't already exist.  Would that already solve the problem?
>    
Yes.

I think the point may be that --tmpdir might need to understand some 
more stuff, to ensure that it stays backward compatible; it'd make sense 
to have to add something to cater for this 'extended' need. And, if it 
changes in that direction, it would also be possible to throw in some 
more stuff (like what envvar should be used rather than the default). 
But that's really optional - if it just stops requiring that the dir 
exists and just creates it (by default with 777, I guess) it'd go a long 
way.
>  Note that you can be as flexible as you want if you distribute your
>  app as 2 files: the actual PerlApp'ed executable and a simple wrapper
>  script or batchfile to run it (untested, just typed into email client):
>    
Oh, absolutely - but one of the defining points with perlapp'ing I 
really, really like is that I get one (1) executable and that's it (ok, 
one per platform I support...). It becomes incredibly easy to move 
around as a completely selfcontained unit. That's not to say I don't 
*also* offer the wrapper - it's required in situations where I have to 
define how to start my tool in a way that's generic to many platforms, 
and so it runs a wrapper to get the correct executable by using uname -s 
-p. But 1) it's far from the only way to run it, and 2) there's the 
slight overhead that it imposes.

Well, it's certainly not critical and I appreciate everyones input. 
Whether it makes sense I let you decide as you obviously have to weigh 
aspects of support, unforeseen trickiness, where it'd on a bug/feature 
request priority scale etc etc.

Thanks,

ken1
_______________________________________________
PDK mailing list
PDK@[...].com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs