On Fri 2008-11-07 12:43, Hendrik Sattler wrote:
> Jed Brown schrieb:
> The FindPkgConfig.cmake module looks broken too, it assumes that
>
> -L/A -la -L/B -lb
>
> is equivalent to
>
> -L/A -L/B -la -lb
>
> >>> I don't see where the above would fail.
> >
>
Jed Brown schrieb:
The FindPkgConfig.cmake module looks broken too, it assumes that
-L/A -la -L/B -lb
is equivalent to
-L/A -L/B -la -lb
>>> I don't see where the above would fail.
>
> This can also fail, but I should have written
>
> -L/B -L/A -la -l
On Thu 2008-11-06 21:03, Jed Brown wrote:
> On Thu 2008-11-06 13:18, Bill Hoffman wrote:
> > Jed Brown wrote:
> >
> >> The FindPkgConfig.cmake module looks broken too, it assumes that
> >>
> >> -L/A -la -L/B -lb
> >>
> >> is equivalent to
> >>
> >> -L/A -L/B -la -lb
> >>
> > I don't see where t
On Thu 2008-11-06 13:18, Bill Hoffman wrote:
> Jed Brown wrote:
>
>> The FindPkgConfig.cmake module looks broken too, it assumes that
>>
>> -L/A -la -L/B -lb
>>
>> is equivalent to
>>
>> -L/A -L/B -la -lb
>>
> I don't see where the above would fail.
If /A/libb exists, but is ABI-incompatible w
Jed Brown wrote:
The FindPkgConfig.cmake module looks broken too, it assumes that
-L/A -la -L/B -lb
is equivalent to
-L/A -L/B -la -lb
I don't see where the above would fail.
To get fully resolved paths, I think it needs to do something like what
is in my FindPETSc.cmake. PkgConfig d
On Wed 2008-11-05 21:05, Bill Hoffman wrote:
> Jed Brown wrote:
>> On Wed 2008-11-05 23:02, Csaba Halász wrote:
>>> Yes, I have just run into this very problem (see my earlier mail about
>>> libtiff)
>>> I just made some try-compile tests to check for known possible dependencies.
>>> I hoped someb
Jed Brown wrote:
On Wed 2008-11-05 23:02, Csaba Halász wrote:
Yes, I have just run into this very problem (see my earlier mail about libtiff)
I just made some try-compile tests to check for known possible dependencies.
I hoped somebody with more cmake experience could offer some insight,
but did
On Wed 2008-11-05 23:02, Csaba Halász wrote:
> Yes, I have just run into this very problem (see my earlier mail about
> libtiff)
> I just made some try-compile tests to check for known possible dependencies.
> I hoped somebody with more cmake experience could offer some insight,
> but didn't get a
On Wed, Nov 5, 2008 at 9:29 PM, Jed Brown <[EMAIL PROTECTED]> wrote:
>
> Here is an extremely simple test case that is broken on every
> platform where libtiff is a static library.
>
> http://59a2.org/files/cmake-tiff.tar.gz
>
> CMake configures successfully, but the build fails with lots of
> unr
I hope clarifies the core problem I rambled on about in my last message.
Suppose I am building project Foo which depends on libA which has an
optional dependency on libB. It looks like everyone just does
find_library (A_LIBRARY A)
and calls it good. If libA is a shared library, the linker ca
10 matches
Mail list logo
