[gnutls-devel] GnuTLS | build: allow override guile system location (!968)

Development of GNU's TLS library gnutls-devel at lists.gnutls.org
Tue Apr 9 17:55:58 CEST 2019




@mbakke I have tried to strictly follow the guile.m4 patterns. The macro defines distinct variable to be used by application:
```
GUILE_SITE
GUILE_SITE_CCACHE
GUILE_EXTENSION
```

There is no default, there is no convention, there is no fallback nor assumption, all are taken from guile package using pkg-config (in recent version) or by executing guile (in older version).

I do not think gnutls should make any assumption of the structure if upstream does not.

The version component within the path is important only if you install the files into guile directories, as if you install it in custom location you need to configure guile to search in that location in any case. I would have understood if the pattern of guile.m4 was to detect all available guile packages installed in the system and use all to build the package, however, only one is installed. This means that a package such as gnutls cannot be *easily* installed while supporting multiple versions.

So I do not think that the version component is required for custom location. However, you can use the guile macros in order to have this easily, by using something like:

```
   ...
   --with-guile-site-dir='/opt/share/guile/$(GUILE_EFFECTIVE_VERSION)' \
   --with-guile-site-cache='$(guilemoduledir)/site-ccache' \
   --with-guile-extensions='$(guilemoduledir)/extensions' \
   ...
```

What do you think?

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/968#note_159013347
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20190409/265b7f87/attachment.html>


More information about the Gnutls-devel mailing list