unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Ricardo Wurmus <rekado@elephly.net>
To: Zelphir Kaltstahl <zelphirkaltstahl@posteo.de>
Cc: guile-user@gnu.org
Subject: Re: build system for pure Guile library (was Re: Help making a GNU Guix package for pure GNU Guile library)
Date: Thu, 04 Feb 2021 01:09:08 +0100	[thread overview]
Message-ID: <87v9b8elsr.fsf@elephly.net> (raw)
In-Reply-To: <955c4811-724a-4f9c-1704-59a21b5d9916@posteo.de>


Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> writes:

> Do you have an example for when one would bake in
> system-specific data-paths?

To satisfy distribution packaging standards your project files may end
up in different directories and cannot assume that the relative relationship
between files remains unchanged.  So if you include images, for example,
and your code loads them then your code cannot assume that they are both
in the same directory.

Your compiled code may end up in a sub-directory of
${prefix}/lib/guile/3.0/site-ccache while your image data might end up
in ${prefix}/share/${application_name}/images.  Or it could be something
completely different.  Conventional “configure” scripts (as generated by
autoconf) give the user the ability to overwrite default locations by
passing “--prefix”, “--localstatedir”, “--libdir”, “--datadir”,
“--datarootdir”, etc.

The fewer assumptions your code makes about locations the happier the
distro packagers will be.  Autoconf and Automake let you record
configured locations by replacing @placeholders@ in template files
ending on “.in”.  Often you’d have a config.scm.in that contains
references to these placeholders and is converted to config.scm during
the run of the “configure” script.

-- 
Ricardo



  reply	other threads:[~2021-02-04  0:09 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-30 17:17 Help making a GNU Guix package for pure GNU Guile library Zelphir Kaltstahl
2021-01-30 17:55 ` Jérémy Korwin-Zmijowski
2021-01-30 19:56   ` divoplade
2021-01-31  3:26   ` Zelphir Kaltstahl
2021-01-30 18:35 ` John Cowan
2021-01-30 19:43   ` Dr. Arne Babenhauserheide
2021-01-30 20:16     ` divoplade
2021-01-30 21:15 ` Ricardo Wurmus
2021-01-31  0:26   ` build system for pure Guile library (was Re: Help making a GNU Guix package for pure GNU Guile library) pelzflorian (Florian Pelz)
2021-01-31  6:29     ` Ricardo Wurmus
2021-01-31 14:16       ` Zelphir Kaltstahl
2021-01-31 15:38         ` Dr. Arne Babenhauserheide
2021-02-03 23:07           ` Zelphir Kaltstahl
2021-02-04  0:09             ` Ricardo Wurmus [this message]
2021-02-03 18:31         ` Adriano Peluso
2021-01-31  3:19   ` Help making a GNU Guix package for pure GNU Guile library Zelphir Kaltstahl
2021-02-03 18:43     ` Adriano Peluso
2021-02-03 23:12       ` Zelphir Kaltstahl

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://www.gnu.org/software/guile/

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

  git send-email \
    --in-reply-to=87v9b8elsr.fsf@elephly.net \
    --to=rekado@elephly.net \
    --cc=guile-user@gnu.org \
    --cc=zelphirkaltstahl@posteo.de \
    /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.
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).