diff mbox series

[bug#41150] gnu: Add powerstat.

Message ID 20200509151509.11424-1-me@tobias.gr
State Accepted
Headers show
Series [bug#41150] gnu: Add powerstat. | expand

Checks

Context Check Description
cbaines/applying patch fail View Laminar job

Commit Message

guix--- via Guix-patches via May 9, 2020, 3:15 p.m. UTC
* gnu/packages/linux.scm (powerstat): New public variable.
---
 gnu/packages/linux.scm | 44 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

2.26.2

Comments

Mathieu Othacehe May 9, 2020, 5:01 p.m. UTC | #1
Hey Tobias,

> +    (arguments
> +     `(#:make-flags
> +       (list "CC=gcc"

Hard-coding CC this way will prevent cross-compilation. You can have a
look to "crda" or "libaio" for examples.

As this is a recurring pattern, we should find a way to add it somewhere
in the build-system. But for now, the ugly snippet appending target
should work :).

Otherwise this looks fine!

Thanks,

Mathieu
guix--- via Guix-patches via May 9, 2020, 5:32 p.m. UTC | #2
Mathieu,

Mathieu Othacehe 写道:
> Hard-coding CC this way will prevent cross-compilation. You can 
> have a
> look to "crda" or "libaio" for examples.

Eh?  This is the first time anyone's ever mentioned that.  Thanks! 
It's obvious how much cross-compilation means to me.

(You realise there are *hundreds* of CC=gcc lines in current Guix, 
right?)

Don't get me wrong: I love that Guix still cares so much about 
cross-compilation, and the tremendous effort I see in the logs 
every month to make it work better, when (at least a few years 
ago) it was all the rage to declare it dead since VMs exist or 
something.

> As this is a recurring pattern, we should find a way to add it 
> somewhere
> in the build-system. But for now, the ugly snippet appending 
> target
> should work :).

I agree that handling (only) standard GNU variables[0] in the GNU 
build system makes sense.

I'll add the snippet of power.

Kind regards,

T G-R

[0]: 
https://www.gnu.org/prep/standards/standards.html#Utilities-in-Makefiles
Jean-Baptiste Note May 9, 2020, 8:03 p.m. UTC | #3
Hi there,

There are actually more than 300 such instances, and counting...

Couldn't we get a "magic" variable %target-cc like we have
%output, %outputs -- then we could just stubstitute gcc for this
variable...

I would do it, if I only knew where these are defined, but my scheme
skills are definitely lacking :)

Kind regards,
Jean-Baptiste
guix--- via Guix-patches via May 9, 2020, 8:42 p.m. UTC | #4
Mathieu again,

Mathieu Othacehe 写道:
> Hard-coding CC this way will prevent cross-compilation. You can 
> have a
> look to "crda" or "libaio" for examples.

Do you happen to know why libaio specifies the full path to gcc 
(only) when cross-compiling?  I didn't bother modifying it to 
test.

I cross-built powerstat for aarch64 on my laptop (then ran it by 
accident -- modern GNU/Linux is mad).  I'm not restricting 
platforms (yet) since my knowledge of ACPI support outside of x86 
does not exist.

Pushed as 510a8eb1b8b4f2686606e427b8965c126b81ed8a.

Thanks!

T G-R
guix--- via Guix-patches via May 9, 2020, 9:04 p.m. UTC | #5
Jean-Baptiste!

Jean-Baptiste Note 写道:
> There are actually more than 300 such instances

*Hundreds*! :-p

On a positive note there are 3 fewer occurences on c-u (308) than 
master (311).

I used a simple ‘grep CC=gcc | wc -l’; I suspect you did something 
similar.

> and counting...

It shouldn't increase if people posts their patches for review 
(...and they actually get reviewed...).  CC=gcc is an old habit 
but not difficult to break.

> Couldn't we get a "magic" variable %target-cc like we have
> %output, %outputs -- then we could just stubstitute gcc for this
> variable...

I'm (not yet?) (no longer?) convinced that's a good idea once 
gnu-build-system takes care of those 308 packages and we're left 
with the exceptions.

When I replied to Mathieu's last mail I hadn't looked at the code 
yet:

  (let ((target ,(%current-target-system)))
    (list (string-append "CC=" (if target
                                   (string-append target "-gcc")
                                   "gcc"))))

To me, abstracting that is beyond overkill.

However, I don't know much about cross-compiling.  TBH I'd be 
sowewhat surprised if none of the CROSS-* procedures I regularly 
scroll past do something like this already.

> I would do it, if I only knew where these are defined, but my 
> scheme
> skills are definitely lacking :)

Mainly (gnu packages cross-base).

Kind regards,

T G-R, currently building kernels to properly answer your 
hibernation mails...
guix--- via Guix-patches via May 9, 2020, 9:10 p.m. UTC | #6
Tobias Geerinckx-Rice 写道:
> Jean-Baptiste Note 写道:
>> I would do it, if I only knew where these are defined, but my 
>> scheme
>> skills are definitely lacking :)
>
> Mainly (gnu packages cross-base).

...or if you mean the % friends: (guix utils).  %target-gcc could 
be computed at evaluation (as opposed to build) time so is 
relatively simple [see previous mail for ‘too simple’ argument].

Kind regards,

T G-R
Mathieu Othacehe May 10, 2020, 7:24 a.m. UTC | #7
Hey,

> Do you happen to know why libaio specifies the full path to gcc (only) when
> cross-compiling?  I didn't bother modifying it to test.

Just tested, this does not seem useful.

> I cross-built powerstat for aarch64 on my laptop (then ran it by accident --
> modern GNU/Linux is mad).  I'm not restricting platforms (yet) since my
> knowledge of ACPI support outside of x86 does not exist.

It's for sure less common than on x86, but it seems that it exists, see:
https://www.kernel.org/doc/Documentation/arm64/arm-acpi.txt.

> Pushed as 510a8eb1b8b4f2686606e427b8965c126b81ed8a.

Thanks for fixing it :)

Mathieu
diff mbox series

Patch

diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index d2bffe8d8c..0d558f0277 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -1195,7 +1195,50 @@  at login.  Local and dynamic reconfiguration are its key features.")
 ;;; Miscellaneous.
 ;;;
 
+(define-public powerstat
+  (package
+    (name "powerstat")
+    (version "0.02.22")
+    (source
+     (origin
+       (method url-fetch)
+       (uri (string-append "https://kernel.ubuntu.com/~cking/tarballs/"
+                           "powerstat/powerstat-" version ".tar.gz"))
+       (sha256
+        (base32 "0r355b9syqa2nhfy8ksvxyy5d58v0isf983842js091s6liy0x7g"))))
+    (build-system gnu-build-system)
+    (arguments
+     `(#:make-flags
+       (list "CC=gcc"
+             (string-append "prefix=" (assoc-ref %outputs "out")))
+       #:tests? #f                      ; no test suite
+       #:phases
+       (modify-phases %standard-phases
+         (add-after 'unpack 'respect-$prefix
+           ;; https://bugs.launchpad.net/ubuntu/+source/powerstat/+bug/1877744
+           (lambda _
+             (substitute* "Makefile"
+               (("DIR=/usr/") "DIR=$(prefix)/"))
+             #t))
+         (delete 'configure))))         ; no configure script
+    (home-page "https://kernel.ubuntu.com/~cking/powerstat/")
+    (synopsis "Measure system power consumption")
+    (description
+     "Powerstat measures and reports your computer's power consumption in real
+time.  On mobile PCs, it uses ACPI battery information to measure the power
+drain of the entire system.
+
+Powerstat can also report @acronym{RAPL, Running Average Power Limit} power
+domain measurements.  These are available only on some hardware such as Intel
+Sandybridge and newer, and cover only part of the machine's components such as
+CPU, DRAM, and graphics.  However, they provide accurate and immediate readings
+and don't require a battery at all.
+
+The output is like @command{vmstat} but also shows power consumption statistics:
+at the end of a run, @command{powerstat} will calculate the average, standard
+deviation, and minimum and maximum values.  It can show a nice histogram too.")
+    (license license:gpl2)))
+
 (define-public psmisc
   (package
     (name "psmisc")
--