[24079] trunk/base/src/pextlib1.0/find.c

[Jordan K. Hubbard]

On Apr 16, 2007, at 2:23 PM, Kevin Ballard wrote:

> Unlike xinstall/install, find is a command that's far more likely to  
> be used in the MacPorts base code than in a Portfile. Making it  
> match the find command-line usage simply makes it more complicated  
> to use, since it doesn't actually match the command-line usage. And  
> I'm not sure why you're arguing against my changes in this context,  
> since your implementation didn't match command-line usage either.

You're right, neither of our implementations was the find(1)  
counterpart that xinstall is to install(1).  However, you've already  
renamed your find so I guess this point is somewhat moot and now we  
simply need to define the feature set of the find procedure.  I hope  
we're at least on the same page with respect to using that proc  
predominantly from Portfiles vs from base?


>> find file src {string match *.o $file} {file delete $file}
>
> Except, of course, that what you just typed wouldn't work. It would  
> find all the object files in the src directory, but not in any of  
> its subdirectories because it wouldn't match any of its  
> subdirectories.

Well, again, you don't need to tell find(1) to traverse subdirs so I  
wasn't expecting that it needed to be explicit in this case either.    
If I just wanted to do file ops within the current directory, I'd use  
glob and eval. :-)


> I think the biggest problem here is you're optimizing for Portfile  
> use case while I'm optimizing for MacPorts base code use case. Why  
> am I doing this? Because I know right off the bat two places where  
> this is useful in base code - the delete proc in portutil and  
> pippings new +universal build stuff for ports like openssl that need  
> two single-architecture builds.

Well, perhaps now that we've bifurcated, we can satisfy the needs of  
both.   So, shall we start defining the behavior of find before doing  
the implementation and avoid the risk of getting into unnecessary  
arguments post-facto? :-)

Incidentally, I hope you've also twigged to the fact that modifying  
someone else's code in an OSS project is almost always bound to lead  
to a more heated discussion than if you'd actually discussed your  
proposed changes in advance and allowed for public comment before  
changing anything.  MacPorts isn't unique in this way - if you'd gone  
and hacked on one of *BSD or Linux's device drivers and committed the  
changes without saying anything first, well, let's just say this  
conversation would still be burning hot with lots of folks piling on.   
MacPorts is small enough that this doesn't really happen yet, but the  
principles remain the same and once MP gets bigger, you'll see an  
increasing need for discussion in advance of "svn commit".

- Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20070416/e048d083/attachment.html