all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Danny Milosavljevic <dannym@scratchpost.org>
Cc: guix-devel@gnu.org
Subject: Re: [PATCH] gnu: dub: Patch pkg-config name.
Date: Tue, 07 Feb 2017 15:13:49 +0100	[thread overview]
Message-ID: <87shnqay1u.fsf@gnu.org> (raw)
In-Reply-To: <20170203183805.30a5fb1f@scratchpost.org> (Danny Milosavljevic's message of "Fri, 3 Feb 2017 18:38:05 +0100")

Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> On Fri, 03 Feb 2017 17:49:38 +0100
> ludo@gnu.org (Ludovic Courtès) wrote:
>
>> I think ‘dub-build-system’ could add it as an implicit input, much like
>> ‘gnu-build-system’ adds binutils as an implicit input.
>
> Okay, but it's directly used only by dub (it its function of building D packages).
>
> I don't think D packages themselves even know what pkg-config is.
>
> The ldc 1.1.0 sources don't even mention "pkg-config" once - neither do any of the D packages I tried except gtk-d. That one mentions it in comments how to invoke gdc (which we didn't package) and rdmd (rdmd source itself doesn't mention pkg-config either) - both are in shell expressions like gdc CoreGL.d `pkg-config gtkd-3 gl --cflags --libs` and rdmd `pkg-config gtkd-3 --cflags` -L-lGL -L-ldl CoreGL.d). No non-comment reference at all.

OK.

> That said, we could add pkg-config as an implicit input so that if D packages decided to directly use it in the future they'd pick up the same one.

Yeah.

>> Or we could simply let people add pkg-config as an input when it’s
>> necessary, just like we do for ‘gnu-build-system’ packages.
>
> dub itself does automatically use pkg-config.
> It's as if make always used pkg-config (whether you write "pkg-config" into a Makefile or not).
>
> Also, if pkg-config is not available dub will silently fallback to guessing. It will not fail (and that's bad!).

OK.

Well I think the conclusion is that (1) we really need to make sure DUB
has pkg-config around one way or another, and (2) of all the solutions
we discussed, I don’t see one that is significantly “better” than the
other (it was worth discussing them though, because in many cases
there’s a solution that “looks better”).

So I’d say proceed as you prefer.

Thanks for taking the time to explain!

Ludo’.

      reply	other threads:[~2017-02-07 14:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-31 16:00 [PATCH] gnu: dub: Patch pkg-config name Danny Milosavljevic
2017-02-01 22:22 ` Ludovic Courtès
2017-02-02 19:36   ` Danny Milosavljevic
2017-02-03 15:14     ` Danny Milosavljevic
2017-02-03 16:49     ` Ludovic Courtès
2017-02-03 17:38       ` Danny Milosavljevic
2017-02-07 14:13         ` 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

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

  git send-email \
    --in-reply-to=87shnqay1u.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=dannym@scratchpost.org \
    --cc=guix-devel@gnu.org \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.