On 10/6/16 1:37 AM, Daniel Macks wrote:
> On Wed, 5 Oct 2016 21:27:19 -0500, Hanspeter Niederstrasser  wrote:
> >
> >Building scite-3.4.1-1 with f-p-p-0.30 gets the following error:
> >
> >   fink-package-precedence --depfile-ext='\.(mak|d)' .
> >Scanning /\.(mak|d)$/ dependency files...
> >  ./scintilla/gtk/Accessor.d
> >...
> >  ./scite/gtk/Widget.d
> >  ./scite/win32/deps.mak
> >  ./scite/win32/scite.mak
> >Use of uninitialized value $abs in string ne at 
> /sw/bin/fink-package-precedence line 164.
> >Use of uninitialized value $abs in exists at 
> /sw/bin/fink-package-precedence line 167.
> >Use of uninitialized value $abs in hash element at 
> /sw/bin/fink-package-precedence line 167.
> >fileparse(): need a valid pathname at /sw/bin/fink-package-precedence 
> line 169.
> >
> >When I downgrade f-p-p to 0.29, the f-p-p check works as expected with no 
> errors.

> (apologies in advance if this message is a formatting mess...new email
> client)I don't see that with scite-3.4.1-1 on my 10.11. But my f-p-p
> call is just:fink-package-precedence --depfile-ext='\.(d)' .I only see
> it if I also check .mak. The you get is triggered by the following line
> in scintilla/test/unit/test.mak:INCLUDEDIRS = /I../../include
> /I../../src /I../../lexlib
> Not surprising that those pathnames break a
> parser that looks at pathnames on the local live system. Older f-p-p was
> lax about trying to process paths that were not absolute and canonical.
> So first, this path is clearly(?) an upstream bug, or targetted for a
> toolchain other than normal compilers (maybe something Windows-like that
> uses leading slash instead of hypen as CLI flag character?). And second,
> what is in the .mak that is not already in the .d? Easy enough to
> tighten f-p-p (or add a heuristic for things to give up and skip), but
> not sure what a *valid* trigger would look like.dan

The removal of .mak from the f-p-p check in scite-3.4.4 is on me. I 
removed them when I updated CVS to scite-3.4.4 because it was failing 
f-p-p, and I only saw the scite/win32/*.mak entries, so I thought them 
unnecessary to check.

Hanspeter


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Reply via email to