On Nov 9, 2005, at 9:51 PM, Trevor Harmon wrote:
Unfortunately, I don't know of any such tool for Java packages,
which is what I've mainly been submitting to Fink. Same problem
with Perl, Python, and so on. Anybody know of otool equivalents for
these languages?
More good advice for findin
On Nov 9, 2005, at 9:51 PM, Trevor Harmon wrote:
Unfortunately, I don't know of any such tool for Java packages,
which is what I've mainly been submitting to Fink. Same problem
with Perl, Python, and so on. Anybody know of otool equivalents for
these languages?
For Perl, the best tools ar
On Wed, 9 Nov 2005 19:51:39 -0800
Trevor Harmon <[EMAIL PROTECTED]> wrote:
> So...you would risk broken packages just to save yourself some compile time?
no. not to myself, to the rest of fink users out there. I make my job harder no
doubt about it.
but it annoys the hell out of me when I see a
On 11/9/05, Trevor Harmon wrote:
> Unfortunately, I don't know of any such tool for Java packages, which
> is what I've mainly been submitting to Fink. Same problem with Perl,
> Python, and so on. Anybody know of otool equivalents for these
> languages?
For python, try 'python -v your-script-here
On Nov 9, 2005, at 5:19 PM, Rogue wrote:
I disagree respectfully. I have in the past avoided (trying out)
many packages because the Dep list was unreasonably long. I tend to
be minimalist, not the safest approach undoutedly, but it is worth
it in the long run IMHO.
Indirect dependencies i
On Wednesday, 09 November 2005 at 22:24, Kevin Horton wrote:
> On 9-Nov-05, at 19:30 , David Bacher wrote:
> It isn't obvious to me how I interpret the output of otool -L. Some
> lines can be connected to obvious fink packages, but many don't
> directly match up. Is there some way to find wh
On 9-Nov-05, at 19:30 , David Bacher wrote:On 11/9/05, Trevor Harmon <[EMAIL PROTECTED]> wrote: I do basically the same thing. It's largely a trial-and-errorprocess, unfortunately. And even then, sometimes you still don't knowwhether there is some dynamic dependency that you don't know aboutuntil i
On Wed, 9 Nov 2005 16:12:33 -0800
Trevor Harmon <[EMAIL PROTECTED]> wrote:
> Also, I generally try to overestimate in deciding what packages go
> into Depends. If I see something only looks like it *might* be a
> dependency, I go ahead and add it. Better to have too many
> dependencies than
On 11/9/05, Trevor Harmon <[EMAIL PROTECTED]> wrote:
I do basically the same thing. It's largely a trial-and-errorprocess, unfortunately. And even then, sometimes you still don't knowwhether there is some dynamic dependency that you don't know aboutuntil it fails at runtime.
I'm sure it doesn't
On Nov 9, 2005, at 3:12 PM, Koen van der Drift wrote:
I'm not an 'old pro', but what I usually do for a new package is to
remove all non-essential packages (eg with FinkCommander). And then
start from scratch to compile the package. Then one by one I start
to add packages based on the error
On Nov 9, 2005, at 6:01 PM, Kevin Horton wrote:
I have created a few fink packages, but I always find it a struggle
to determine what to list as Depends, and BuildDepends. Sometimes
I can glean a few hints from studying the output of the build
process, and sometimes a failed build is a go
I have created a few fink packages, but I always find it a struggle
to determine what to list as Depends, and BuildDepends. Sometimes I
can glean a few hints from studying the output of the build process,
and sometimes a failed build is a good clue. But I am never sure to
have captured ev
12 matches
Mail list logo
