Global modification of #:make-flags

Global modification of #:make-flags

[Marek Paśnikowski]

Hello

In order to prevent the XY problem, here is my goal: Rebuild the entire
system with -Os optimization level.  It is an experiment into viability
of hardware-targeted optimizations.

The [2.1 Packaging Tutorial][1] of the Cookbook mentions that it is
possible to pass a #:make-flags argument to a list of packages.
Unfortunately, no explanation is given how to implement this
functionality, and which exactly lists of packages does it apply to.

Does the Guix System have a facility similar to Gentoo's [make.conf][2],
where a default optimization set can be declared? A potential problem is
with packages that are dependencies of services, like %desktop-services.
I hope those also would inherit the changes.

[1]: https://guix.gnu.org/cookbook/en/html_node/Packaging-Tutorial.html
[2]: https://wiki.gentoo.org/wiki//etc/portage/make.conf#CFLAGS_and_CXXFLAGS

Re: Global modification of #:make-flags

[Sarthak Shah]

[-- Attachment #1: Type: text/plain, Size: 1333 bytes --]

Hey Marek,
You might find my work on Parameterized Packages interesting:

https://blog.lispy.tech/parameterized-packages-the-project-completion-update.html

Unfortunately, it hasn't been merged into the main branch yet, however you
should be able to make everything use -Os with the patch.

Regards,

Sarthak.

On Tue, Aug 20, 2024, 15:35 Marek Paśnikowski <marek@marekpasnikowski.pl>
wrote:

> Hello
>
> In order to prevent the XY problem, here is my goal: Rebuild the entire
> system with -Os optimization level.  It is an experiment into viability
> of hardware-targeted optimizations.
>
> The [2.1 Packaging Tutorial][1] of the Cookbook mentions that it is
> possible to pass a #:make-flags argument to a list of packages.
> Unfortunately, no explanation is given how to implement this
> functionality, and which exactly lists of packages does it apply to.
>
> Does the Guix System have a facility similar to Gentoo's [make.conf][2],
> where a default optimization set can be declared? A potential problem is
> with packages that are dependencies of services, like %desktop-services.
> I hope those also would inherit the changes.
>
> [1]: https://guix.gnu.org/cookbook/en/html_node/Packaging-Tutorial.html
> [2]:
> https://wiki.gentoo.org/wiki//etc/portage/make.conf#CFLAGS_and_CXXFLAGS
>
>

[-- Attachment #2: Type: text/html, Size: 2074 bytes --]

Re: Global modification of #:make-flags

[Suhail Singh]

Sarthak Shah <shahsarthakw@gmail.com> writes:

> https://blog.lispy.tech/parameterized-packages-the-project-completion-update.html
>
> Unfortunately, it hasn't been merged into the main branch yet, however
> you should be able to make everything use -Os with the patch.

The blog doesn't mention a related debbugs issue.  If the goal is still
to eventually merge the changes after, possibly, some changes, it might
help if there were an issue where discussion could be consolidated.
WDYT?

-- 
Suhail

Re: Global modification of #:make-flags

[Sarthak Shah]

[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]

Hey Suhail,
I think starting a debbugs issue could be a good idea once everyone's
onboard with getting this patch merged!
Right now, from what I gather, there are some more important conversations
to be had, mainly with the Guix maintainers, as merging this patch could
lead to a sharp, unexpected increase in complexity if we do not have proper
guidelines and procedures in place for parameterization.

I would love to hear more thoughts on this, as I'm not very aware about how
to proceed either.

Regards,
Sarthak.

On Tue, Aug 20, 2024, 18:43 Suhail Singh <suhailsingh247@gmail.com> wrote:

> Sarthak Shah <shahsarthakw@gmail.com> writes:
>
> >
> https://blog.lispy.tech/parameterized-packages-the-project-completion-update.html
> >
> > Unfortunately, it hasn't been merged into the main branch yet, however
> > you should be able to make everything use -Os with the patch.
>
> The blog doesn't mention a related debbugs issue.  If the goal is still
> to eventually merge the changes after, possibly, some changes, it might
> help if there were an issue where discussion could be consolidated.
> WDYT?
>
> --
> Suhail
>

[-- Attachment #2: Type: text/html, Size: 1839 bytes --]

Re: Global modification of #:make-flags

[Suhail Singh]

Sarthak Shah <shahsarthakw@gmail.com> writes:

> I think starting a debbugs issue could be a good idea once everyone's
> onboard with getting this patch merged!

I'm not sure I agree that consensus has to be a pre-requisite for
creating an issue.

> Right now, from what I gather, there are some more important conversations
> to be had, mainly with the Guix maintainers, as merging this patch could
> lead to a sharp, unexpected increase in complexity if we do not have proper
> guidelines and procedures in place for parameterization.

Creation of an issue doesn't imply that the patch (series) has to be
merged (in its current form or otherwise).  On the other hand, creation
of an issue allows for feedback to be gathered in one place.  In fact, I
would argue that there's value in creating an issue even before any code
towards a patch has been written (by, say, submitting a feature request
to <bug-guix@gnu.org>).

If not on an issue, where do you intend to have the conversations you
alluded to above?

-- 
Suhail

Re: Global modification of #:make-flags

[Marek Paśnikowski]

Sarthak Shah <shahsarthakw@gmail.com> writes:

> Hey Marek,
> You might find my work on Parameterized Packages interesting:
>
> https://blog.lispy.tech/parameterized-packages-the-project-completion-update.html
>
> Unfortunately, it hasn't been merged into the main branch yet, however you should be able to make everything use -Os with the
> patch.
>

Thank you.

I have read the blog post and the linked second update and I am not sure
how should I use it to apply CFLAGS to all the system packages.

I really would like to give it a try on my system, but I am
struggling with the patch application.  I have tried using both a patch
and a snippet fields of an origin record, with no success.

On the snippet way I have no idea how to transform the (local-file)
object representing the patch file into a string to be part of (invoke
"patch").

On the patch way, the build process fails with the following error log:
...
`File Makefile.am is read-only; trying to patch anyway
patching file Makefile.am
Hunk #1 FAILED at 17.
Hunk #2 succeeded at 117 (offset 3 lines).
1 out of 2 hunks FAILED -- saving rejects to file Makefile.am.rej
patching file guix/parameters.scm
File guix/transformations.scm is read-only; trying to patch anyway
patching file guix/transformations.scm
Hunk #1 succeeded at 37 (offset 1 line).
Hunk #2 succeeded at 356 (offset 1 line).
Hunk #3 succeeded at 983 (offset 19 lines).
Hunk #4 succeeded at 1031 (offset 19 lines).
File guix/ui.scm is read-only; trying to patch anyway
patching file guix/ui.scm
Hunk #2 succeeded at 79 (offset 2 lines).
Hunk #3 succeeded at 1612 (offset 3 lines).
source is at 'guix-1.4.0-24.9a2ddcc-checkout'
applying '/gnu/store/wld7aagwmygimf6rqllrmgyp97hrz70v-parameterization.patch'...
Backtrace:
           5 (primitive-load "/gnu/store/7l0mipjghp0f0k4652axgyyg2vi…")
In ice-9/eval.scm:
    619:8  4 (_ #(#(#<directory (guile-user) 7ffff77f7c80> "gui…") #))
In ice-9/boot-9.scm:
    142:2  3 (dynamic-wind #<procedure 7ffff5472520 at ice-9/eval.s…> …)
In ice-9/eval.scm:
    619:8  2 (_ #(#(#<directory (guile-user) 7ffff77f7c80>)))
In srfi/srfi-1.scm:
    634:9  1 (for-each #<procedure apply-patch (a)> ("/gnu/store/wl…"))
In guix/build/utils.scm:
    812:6  0 (invoke "/gnu/store/210yfax18r2g2inxrml9435ikhfcca6m-p…" …)

guix/build/utils.scm:812:6: In procedure invoke:
ERROR:
  1. &invoke-error:
      program: "/gnu/store/210yfax18r2g2inxrml9435ikhfcca6m-patch-2.7.6/bin/patch"
      arguments: ("--force" "--no-backup-if-mismatch" "-p1" "--input" "/gnu/store/wld7aagwmygimf6rqllrmgyp97hrz70v-parameterization.patch")
      exit-status: 1
      term-signal: #f
      stop-signal: #f
...

Here is the code I used to attempt the patch, excluding module imports:

(define local-files
  '(find-files "."))

(define guix-source
  (package-source guix))

;;;

(define make-files-writable
  `(for-each make-file-writable
	     ,local-files))

(define guix-origin-patches
  (origin-patches guix-source))

(define guix-parameters-patches
  (list "suweren/parameterization.patch"))

(define patch-guix
  '(invoke "patch"
	   "--force"
	   "--no-backup-if-mismatch"
	   "-p1"
	   "--input"
	   "suweren/parameterization.patch"))

;;;

(define guix-parameters-origin-snippet
  `(begin ,make-files-writable
	  ,patch-guix
	  #t))

(define guix-parameters-origin-snippet-modules
  '((guix build utils)))

(define guix-parameters-all-patches
  (append guix-origin-patches
	  guix-parameters-patches))

;;;

(define guix-parameters-origin
  (origin (inherit guix-source)
	  (sha256 (base32 "0823vl88gbgqadc20in9qvxnrd7zhnq047bfvw4gvdsmgxpcpvpx"))
	  (patches guix-parameters-all-patches)
	  ;; (snippet guix-parameters-origin-snippet)
	  ;; (modules guix-parameters-origin-snippet-modules)
	  ))

;;;

(define guix-extra-options
  (list "--gc-keep-derivations=yes"
	"--gc-keep-outputs=yes"))

(define guix-parameters
  (package (inherit guix)
	   (source guix-parameters-origin)))

;;;

;; This function is part of a modify-services clause,
;; and it inherits the default guix configuration.
(define (guix-options configuration-record)
  (guix-configuration (inherit configuration-record)
		      (guix guix-parameters)
		      (extra-options guix-extra-options)))

Re: Global modification of #:make-flags

[Sarthak Shah]

[-- Attachment #1: Type: text/plain, Size: 5402 bytes --]

Hey Marek,
It looks like I need to update the patch as it's failing to apply to
Makefile.am
In the meantime, you could try to apply the one failed hunk in
Makefile.am.rej yourself, that should fix the problem.
Another thing that needs a bit of fixing is that this doesn't work on fresh
Guix repositories, you need to have built Guix once from a repository
before applying the patch. I'll try and fix both of these problems as soon
as I get the time to, but once you've taken care of this it should work
smoothly.

Regards,
Sarthak.

On Wed, Aug 21, 2024, 12:40 Marek Paśnikowski <marek@marekpasnikowski.pl>
wrote:

> Sarthak Shah <shahsarthakw@gmail.com> writes:
>
> > Hey Marek,
> > You might find my work on Parameterized Packages interesting:
> >
> >
> https://blog.lispy.tech/parameterized-packages-the-project-completion-update.html
> >
> > Unfortunately, it hasn't been merged into the main branch yet, however
> you should be able to make everything use -Os with the
> > patch.
> >
>
> Thank you.
>
> I have read the blog post and the linked second update and I am not sure
> how should I use it to apply CFLAGS to all the system packages.
>
> I really would like to give it a try on my system, but I am
> struggling with the patch application.  I have tried using both a patch
> and a snippet fields of an origin record, with no success.
>
> On the snippet way I have no idea how to transform the (local-file)
> object representing the patch file into a string to be part of (invoke
> "patch").
>
> On the patch way, the build process fails with the following error log:
> ...
> `File Makefile.am is read-only; trying to patch anyway
> patching file Makefile.am
> Hunk #1 FAILED at 17.
> Hunk #2 succeeded at 117 (offset 3 lines).
> 1 out of 2 hunks FAILED -- saving rejects to file Makefile.am.rej
> patching file guix/parameters.scm
> File guix/transformations.scm is read-only; trying to patch anyway
> patching file guix/transformations.scm
> Hunk #1 succeeded at 37 (offset 1 line).
> Hunk #2 succeeded at 356 (offset 1 line).
> Hunk #3 succeeded at 983 (offset 19 lines).
> Hunk #4 succeeded at 1031 (offset 19 lines).
> File guix/ui.scm is read-only; trying to patch anyway
> patching file guix/ui.scm
> Hunk #2 succeeded at 79 (offset 2 lines).
> Hunk #3 succeeded at 1612 (offset 3 lines).
> source is at 'guix-1.4.0-24.9a2ddcc-checkout'
> applying
> '/gnu/store/wld7aagwmygimf6rqllrmgyp97hrz70v-parameterization.patch'...
> Backtrace:
>            5 (primitive-load "/gnu/store/7l0mipjghp0f0k4652axgyyg2vi…")
> In ice-9/eval.scm:
>     619:8  4 (_ #(#(#<directory (guile-user) 7ffff77f7c80> "gui…") #))
> In ice-9/boot-9.scm:
>     142:2  3 (dynamic-wind #<procedure 7ffff5472520 at ice-9/eval.s…> …)
> In ice-9/eval.scm:
>     619:8  2 (_ #(#(#<directory (guile-user) 7ffff77f7c80>)))
> In srfi/srfi-1.scm:
>     634:9  1 (for-each #<procedure apply-patch (a)> ("/gnu/store/wl…"))
> In guix/build/utils.scm:
>     812:6  0 (invoke "/gnu/store/210yfax18r2g2inxrml9435ikhfcca6m-p…" …)
>
> guix/build/utils.scm:812:6: In procedure invoke:
> ERROR:
>   1. &invoke-error:
>       program:
> "/gnu/store/210yfax18r2g2inxrml9435ikhfcca6m-patch-2.7.6/bin/patch"
>       arguments: ("--force" "--no-backup-if-mismatch" "-p1" "--input"
> "/gnu/store/wld7aagwmygimf6rqllrmgyp97hrz70v-parameterization.patch")
>       exit-status: 1
>       term-signal: #f
>       stop-signal: #f
> ...
>
> Here is the code I used to attempt the patch, excluding module imports:
>
> (define local-files
>   '(find-files "."))
>
> (define guix-source
>   (package-source guix))
>
> ;;;
>
> (define make-files-writable
>   `(for-each make-file-writable
>              ,local-files))
>
> (define guix-origin-patches
>   (origin-patches guix-source))
>
> (define guix-parameters-patches
>   (list "suweren/parameterization.patch"))
>
> (define patch-guix
>   '(invoke "patch"
>            "--force"
>            "--no-backup-if-mismatch"
>            "-p1"
>            "--input"
>            "suweren/parameterization.patch"))
>
> ;;;
>
> (define guix-parameters-origin-snippet
>   `(begin ,make-files-writable
>           ,patch-guix
>           #t))
>
> (define guix-parameters-origin-snippet-modules
>   '((guix build utils)))
>
> (define guix-parameters-all-patches
>   (append guix-origin-patches
>           guix-parameters-patches))
>
> ;;;
>
> (define guix-parameters-origin
>   (origin (inherit guix-source)
>           (sha256 (base32
> "0823vl88gbgqadc20in9qvxnrd7zhnq047bfvw4gvdsmgxpcpvpx"))
>           (patches guix-parameters-all-patches)
>           ;; (snippet guix-parameters-origin-snippet)
>           ;; (modules guix-parameters-origin-snippet-modules)
>           ))
>
> ;;;
>
> (define guix-extra-options
>   (list "--gc-keep-derivations=yes"
>         "--gc-keep-outputs=yes"))
>
> (define guix-parameters
>   (package (inherit guix)
>            (source guix-parameters-origin)))
>
> ;;;
>
> ;; This function is part of a modify-services clause,
> ;; and it inherits the default guix configuration.
> (define (guix-options configuration-record)
>   (guix-configuration (inherit configuration-record)
>                       (guix guix-parameters)
>                       (extra-options guix-extra-options)))
>
>

[-- Attachment #2: Type: text/html, Size: 6671 bytes --]

Re: Global modification of #:make-flags

[Sarthak Shah]

[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]

Hey Suhail,
I was thinking about having a conversation in a guix-devel email thread
itself.

From my understanding, debbugs issues are meant for technical features or
issues pending implementation, while guix-devel threads are meant for
discussions surrounding Guix and possible features.

This is why I had linked the relevant mailing list thread in my blog post
as well.

Regards,
Sarthak.

On Wed, Aug 21, 2024, 12:25 Suhail Singh <suhailsingh247@gmail.com> wrote:

> Sarthak Shah <shahsarthakw@gmail.com> writes:
>
> > I think starting a debbugs issue could be a good idea once everyone's
> > onboard with getting this patch merged!
>
> I'm not sure I agree that consensus has to be a pre-requisite for
> creating an issue.
>
> > Right now, from what I gather, there are some more important
> conversations
> > to be had, mainly with the Guix maintainers, as merging this patch could
> > lead to a sharp, unexpected increase in complexity if we do not have
> proper
> > guidelines and procedures in place for parameterization.
>
> Creation of an issue doesn't imply that the patch (series) has to be
> merged (in its current form or otherwise).  On the other hand, creation
> of an issue allows for feedback to be gathered in one place.  In fact, I
> would argue that there's value in creating an issue even before any code
> towards a patch has been written (by, say, submitting a feature request
> to <bug-guix@gnu.org>).
>
> If not on an issue, where do you intend to have the conversations you
> alluded to above?
>
> --
> Suhail
>

[-- Attachment #2: Type: text/html, Size: 2258 bytes --]

Re: Global modification of #:make-flags

[Marek Paśnikowski]

Sarthak Shah <shahsarthakw@gmail.com> writes:

> Another thing that needs a bit of fixing is that this doesn't work on
> fresh Guix repositories, you need to have built Guix once from a
> repository before applying the patch.

Hold on.  Is this a patch to the guix /repository/, not /package/?  That
would explain the patch failure.  Now I need to go and learn how to
programmaticaly patch a channel.

Any pointers on how to globally set the "-Os" CFLAG?

Re: Global modification of #:make-flags

[Sarthak Shah]

[-- Attachment #1: Type: text/plain, Size: 1715 bytes --]

Hey Marek,
Yep, this is a patch for the repository. I haven't figured out how to
programmatically patch it yet either; the original idea was to use
time-machine, but it was causing some errors that I wasn't able to debug.
Perhaps it's time I give it another shot.

As for -Os, check out the GCC optimization flags example in this post:

https://blog.lispy.tech/parameterized-packages-the-second-update.html

You'll have to then specify this parameter for the packages you want to
install, like so:

guix install hello --with-parameter=gcc-oflag=-Os

Back when I was working on it, there were talks about setting up global
transforms for Guix, which is how this patch was supposed to be used
globally. I am not sure if this feature has been added to Guix yet, but
once it is you can then add this transform globally. I have added features
that will check if the build system and any other user defined condition
matches before applying parameterization. Otherwise, you'll have to add
this transform to the packages you need -Os with, which is not very
difficult, just a bit cumbersome...


Regards,

Sarthak.

On Wed, Aug 21, 2024, 13:05 Marek Paśnikowski <marek@marekpasnikowski.pl>
wrote:

> Sarthak Shah <shahsarthakw@gmail.com> writes:
>
> > Another thing that needs a bit of fixing is that this doesn't work on
> > fresh Guix repositories, you need to have built Guix once from a
> > repository before applying the patch.
>
> Hold on.  Is this a patch to the guix /repository/, not /package/?  That
> would explain the patch failure.  Now I need to go and learn how to
> programmaticaly patch a channel.
>
> Any pointers on how to globally set the "-Os" CFLAG?
>
>

[-- Attachment #2: Type: text/html, Size: 2347 bytes --]

Re: Global modification of #:make-flags

[Marek Paśnikowski]

Sarthak Shah <shahsarthakw@gmail.com> writes:

> Hey Marek, Yep, this is a patch for the repository. I haven't figured
> out how to programmatically patch it yet either; the original idea was
> to use time-machine, but it was causing some errors that I wasn't able
> to debug. Perhaps it's time I give it another shot.
>
> As for -Os, check out the GCC optimization flags example in this post:
>
> https://blog.lispy.tech/parameterized-packages-the-second-update.html
>
> You'll have to then specify this parameter for the packages you want
> to install, like so:
>
> guix install hello --with-parameter=gcc-oflag=-Os
>
> Back when I was working on it, there were talks about setting up
> global transforms for Guix, which is how this patch was supposed to be
> used globally. I am not sure if this feature has been added to Guix
> yet, but once it is you can then add this transform globally. I have
> added features that will check if the build system and any other user
> defined condition matches before applying parameterization. Otherwise,
> you'll have to add this transform to the packages you need -Os with,
> which is not very difficult, just a bit cumbersome...
>

Thank you for your patient and informative replies.  Unfortunately, I am
currently not interested in package-specific optimizations, that is not
my goal.

I will be the first to test the global transformations, but right now I
will have better returns on my time investments in other projects
including a router system and continuous integration of my channel
updates.  Or even learning how to work with the e-mail based bug and
patch systems used here.

Ah, the irony — I do see a future where I help to implement the global
transformations.  But to realize this future I need to learn more and
complete my development system.  While having a life outside of
computers... :-)

Re: Global modification of #:make-flags

[Suhail Singh]

Sarthak Shah <shahsarthakw@gmail.com> writes:

> From my understanding, debbugs issues are meant for technical features
> or issues pending implementation, while guix-devel threads are meant
> for discussions surrounding Guix and possible features.

I am no authority on the matter, so please take what I say with a grain
of salt.  However, I have seen technical discussions (on features
not-yet-fully-implemented) happen on the bug and patches mailing lists
in addition to guix-devel.  I don't believe there's a strict rule.  To
an extent it's to the discretion of the individual(s) having the
discussion.

Additionally, having an issue open doesn't preclude one from cc-ing
guix-devel in replies, in case that's desired.  Though, whether that's
/desirable/ is a different matter.

> This is why I had linked the relevant mailing list thread in my blog post
> as well.

It's your prerogative at the end of the day, however, if you would like
others to try out the patches, you may have better luck by creating an
issue where the patch reroll count can be incremented and tracked (and
those interested can follow the progress).

-- 
Suhail

Re: Global modification of #:make-flags

[Ludovic Courtès]

Hi,

Marek Paśnikowski <marek@marekpasnikowski.pl> skribis:

> In order to prevent the XY problem, here is my goal: Rebuild the entire
> system with -Os optimization level.  It is an experiment into viability
> of hardware-targeted optimizations.

Instead of trying to override #:make-flags, which is likely fragile as
it depends on details of each package’s build system, I would use a
strategy similar to that of ‘--tune’.

For ‘--tune’, the ‘tuning-compiler’ procedure in (guix transformations)
produces a compiler wrapper that passes ‘-march=whatever’, and
‘tuned-package’ injects that wrapper in the package of interest.

In fact you could reuse most of the code here to do what you want.  And
we could create a package transformation for ‘-Os’.  Could be neat!

HTH!

Ludo’.

Re: Global modification of #:make-flags

[Sergio Pastor Pérez]

[-- Attachment #1: Type: text/plain, Size: 2956 bytes --]

Hello, Sarthak!

I would like to show interest in having an open issue on the matter.

Suhail Singh <suhailsingh247@gmail.com> writes:

> Sarthak Shah <shahsarthakw@gmail.com> writes:
>> From my understanding, debbugs issues are meant for technical features
[ 6 more citation lines. Click/Enter to show. ]
>> or issues pending implementation, while guix-devel threads are meant
>> for discussions surrounding Guix and possible features.
>
> I am no authority on the matter, so please take what I say with a grain
> of salt.  However, I have seen technical discussions (on features
> not-yet-fully-implemented) happen on the bug and patches mailing lists
> in addition to guix-devel.  I don't believe there's a strict rule.  To
> an extent it's to the discretion of the individual(s) having the
> discussion.

I want to echo Suhail sentiment. My self and other members of the
community have expressed interest in your work through different
channels scattered around the web. This is a recurrent topic, an open
issue would encourage participation and sharing ideas. Even if I try to
be active on most of the available Guix communities, I'm sure I miss
many topics due to the scattered nature of the community. I encourage
you to open an issue so it can be a hub for us.

Regards,
Sergio.
________________________________
From: guix-devel-bounces+sergio.pastorperez=outlook.es@gnu.org <guix-devel-bounces+sergio.pastorperez=outlook.es@gnu.org> on behalf of Suhail Singh <suhailsingh247@gmail.com>
Sent: Wednesday, August 21, 2024 4:37 PM
To: Sarthak Shah <shahsarthakw@gmail.com>
Cc: Suhail Singh <suhailsingh247@gmail.com>; Marek Paśnikowski <marek@marekpasnikowski.pl>; Guix Devel <guix-devel@gnu.org>
Subject: Re: Global modification of #:make-flags

Sarthak Shah <shahsarthakw@gmail.com> writes:

> From my understanding, debbugs issues are meant for technical features
> or issues pending implementation, while guix-devel threads are meant
> for discussions surrounding Guix and possible features.

I am no authority on the matter, so please take what I say with a grain
of salt.  However, I have seen technical discussions (on features
not-yet-fully-implemented) happen on the bug and patches mailing lists
in addition to guix-devel.  I don't believe there's a strict rule.  To
an extent it's to the discretion of the individual(s) having the
discussion.

Additionally, having an issue open doesn't preclude one from cc-ing
guix-devel in replies, in case that's desired.  Though, whether that's
/desirable/ is a different matter.

> This is why I had linked the relevant mailing list thread in my blog post
> as well.

It's your prerogative at the end of the day, however, if you would like
others to try out the patches, you may have better luck by creating an
issue where the patch reroll count can be incremented and tracked (and
those interested can follow the progress).

--
Suhail


[-- Attachment #2: Type: text/html, Size: 8366 bytes --]

Re: Global modification of #:make-flags

[Sergio Pastor Pérez]

Hello Marek.

Marek Paśnikowski <marek@marekpasnikowski.pl> writes:

> Does the Guix System have a facility similar to Gentoo's [make.conf][2],
> where a default optimization set can be declared? A potential problem is
> with packages that are dependencies of services, like %desktop-services.
> I hope those also would inherit the changes.

Please take a look at this thread. It proposes a way to map a
transformation over an operating system record. Allowing you to apply a
transformation to every package of the system.

Ludo suggested a better implementation but it's blocked by this issue[1]

[1] https://issues.guix.gnu.org/71941

Regards,
Sergio.

Re: Global modification of #:make-flags

[Sarthak Shah]

[-- Attachment #1: Type: text/plain, Size: 3366 bytes --]

Dear Sergio and Suhail,
Thank you for showing interest in my work.
I will open an issue on the debbugs as soon as I have time to update my
patch!

Regards,
Sarthak.

On Thu, Aug 22, 2024 at 9:44 PM Sergio Pastor Pérez <
sergio.pastorperez@outlook.es> wrote:

> Hello, Sarthak!
>
> I would like to show interest in having an open issue on the matter.
>
> Suhail Singh <suhailsingh247@gmail.com> writes:
>
> > Sarthak Shah <shahsarthakw@gmail.com> writes:
> >> From my understanding, debbugs issues are meant for technical features
> [ 6 more citation lines. Click/Enter to show. ]
> >> or issues pending implementation, while guix-devel threads are meant
> >> for discussions surrounding Guix and possible features.
> >
> > I am no authority on the matter, so please take what I say with a grain
> > of salt.  However, I have seen technical discussions (on features
> > not-yet-fully-implemented) happen on the bug and patches mailing lists
> > in addition to guix-devel.  I don't believe there's a strict rule.  To
> > an extent it's to the discretion of the individual(s) having the
> > discussion.
>
> I want to echo Suhail sentiment. My self and other members of the
> community have expressed interest in your work through different
> channels scattered around the web. This is a recurrent topic, an open
> issue would encourage participation and sharing ideas. Even if I try to
> be active on most of the available Guix communities, I'm sure I miss
> many topics due to the scattered nature of the community. I encourage
> you to open an issue so it can be a hub for us.
>
> Regards,
> Sergio.
> ------------------------------
> *From:* guix-devel-bounces+sergio.pastorperez=outlook.es@gnu.org
> <guix-devel-bounces+sergio.pastorperez=outlook.es@gnu.org> on behalf of
> Suhail Singh <suhailsingh247@gmail.com>
> *Sent:* Wednesday, August 21, 2024 4:37 PM
> *To:* Sarthak Shah <shahsarthakw@gmail.com>
> *Cc:* Suhail Singh <suhailsingh247@gmail.com>; Marek Paśnikowski <
> marek@marekpasnikowski.pl>; Guix Devel <guix-devel@gnu.org>
> *Subject:* Re: Global modification of #:make-flags
>
> Sarthak Shah <shahsarthakw@gmail.com> writes:
>
> > From my understanding, debbugs issues are meant for technical features
> > or issues pending implementation, while guix-devel threads are meant
> > for discussions surrounding Guix and possible features.
>
> I am no authority on the matter, so please take what I say with a grain
> of salt.  However, I have seen technical discussions (on features
> not-yet-fully-implemented) happen on the bug and patches mailing lists
> in addition to guix-devel.  I don't believe there's a strict rule.  To
> an extent it's to the discretion of the individual(s) having the
> discussion.
>
> Additionally, having an issue open doesn't preclude one from cc-ing
> guix-devel in replies, in case that's desired.  Though, whether that's
> /desirable/ is a different matter.
>
> > This is why I had linked the relevant mailing list thread in my blog post
> > as well.
>
> It's your prerogative at the end of the day, however, if you would like
> others to try out the patches, you may have better luck by creating an
> issue where the patch reroll count can be incremented and tracked (and
> those interested can follow the progress).
>
> --
> Suhail
>
>

[-- Attachment #2: Type: text/html, Size: 8891 bytes --]

Re: Global modification of #:make-flags

[Marek Paśnikowski]

Ludovic Courtès <ludo@gnu.org> writes:

Good afternoon.

I apologise for late reply — I am still catching up with my digital life
backlog.

> Hi,
>
> Marek Paśnikowski <marek@marekpasnikowski.pl> skribis:
>
>> In order to prevent the XY problem, here is my goal: Rebuild the entire
>> system with -Os optimization level.  It is an experiment into viability
>> of hardware-targeted optimizations.
>
> Instead of trying to override #:make-flags, which is likely fragile as
> it depends on details of each package’s build system, I would use a
> strategy similar to that of ‘--tune’.
>
> For ‘--tune’, the ‘tuning-compiler’ procedure in (guix transformations)
> produces a compiler wrapper that passes ‘-march=whatever’, and
> ‘tuned-package’ injects that wrapper in the package of interest.
>
> In fact you could reuse most of the code here to do what you want.  And
> we could create a package transformation for ‘-Os’.  Could be neat!

I appreciate the pointers about transformations.  Did you mean to
suggest to implement a new transformation dedicated to the O levels?
This is how I interpreted your response.

Also, I am still failing to see how I could apply /any/ transformations
to the operating-system records.  I admit, I still know little about
sub-surface features of Guix.

In the adjacent message, Sergio Perez mentioned a map-derivation
function.  The documentation I found about it is /very/ cryptic.

  “Given MAPPING, a list of pairs of derivations, return a derivation
based on DRV where all the 'car's of MAPPING have been replaced by its
'cdr's, recursively.”

  Should I get more familiar with this function, if I want to transform
  operating-system?