unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: "Lluís Batlle i Rossell" <viric@viric.name>
Cc: guix-devel@gnu.org
Subject: Re: CMAKE_LIBRARY_PATH & co.
Date: Mon, 14 Oct 2013 14:31:40 +0200	[thread overview]
Message-ID: <87li1w5903.fsf@gnu.org> (raw)
In-Reply-To: <20131014072305.GA1965@vicerveza.homeunix.net> ("Lluís Batlle i Rossell"'s message of "Mon, 14 Oct 2013 09:23:05 +0200")

Lluís Batlle i Rossell <viric@viric.name> skribis:

> On Mon, Oct 14, 2013 at 09:15:25AM +0200, Ludovic Courtès wrote:
>> Andreas Enge <andreas@enge.fr> skribis:
>> 
>> > commit e78fd4ca636a19bc286747f8d91bda22cd8f08fd
>> > Author: Andreas Enge <andreas@enge.fr>
>> > Date:   Sun Oct 13 18:02:49 2013 +0200
>> >
>> >     guix: Make cmake build system aware of usual paths.
>> >     
>> >     *  guix/build/cmake-build-system.scm (configure): Set CMAKE_LIBRARY_PATH to
>> >          LIBRARY_PATH and CMAKE_INCLUDE_PATH to CPATH.
>> 
>> I think this was discussed on IRC yesterday, but I’m not sure I got it:
>> are these needed because CMake explicitly looks for files in these
>> directories instead of just running the compiler?
>> 
>> That would be a serious flaw of CMake.
>
> Right; for what I understand, FIND_LIBRARY, and FIND_PATH, look for files in
> specific directories. Then cmake takes a decision based in what it finds. A
> shared object, a static lib, ...

Blech.

That’s flawed because CMake’s auto-configuration rules behave
differently from what the compiler/linker actually do.  So its
configuration phase may end up making decisions based on erroneous
information.

Thanks for the explanations,
Ludo’.

      reply	other threads:[~2013-10-14 12:36 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1VVP5Z-0005c4-TI@vcs.savannah.gnu.org>
2013-10-14  7:15 ` CMAKE_LIBRARY_PATH & co Ludovic Courtès
2013-10-14  7:23   ` Lluís Batlle i Rossell
2013-10-14 12:31     ` Ludovic Courtès [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87li1w5903.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=viric@viric.name \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).