jpm and a janet-build-system

2022-09-06 Thread jgart
Hi,

has anyone done any recent research on incorporating jpm into a 
janet-build-system?

https://github.com/janet-lang/jpm

all best,

jgart



Progress with automating testing of patches

2022-09-06 Thread Christopher Baines
Hey!

I think I sent the last message to guix-devel on this topic back in
February [1].

1: https://lists.gnu.org/archive/html/guix-devel/2022-02/msg00102.html

I haven't had a lot of time or motivation this year, but I've still been
trying to chip away at this.

The recent new thing is that I've joined up the uncompleted work to test
changes (patches and branches) with some thoughts from early last year
about a QA page [2].

2: https://lists.gnu.org/archive/html/guix-devel/2021-02/msg00096.html

While the data service solves the hard problem of knowing what's changed
with some patches or a branch, and the build coordinator solves the hard
problem of building things and doing something with the results, there
was a need for something else to address the other hard problem of tying
these tools together and communicating the information. I think this QA
service is a good fit.

Since it's easier to iterate once there's something visible, I've just
stuck what I've got so far on the internet, it's available at:

  https://qa.guix.gnu.org/

The code is here [3] and I've put a list of ideas in the README.

3: https://git.cbaines.net/guix/qa-frontpage/about/

Currently, there's a page which lists issues, and pages for individual
issues that show build and lint warning changes. Behind the scenes, it's
also submitting builds to the build coordinator for the packages
affected by patches (for x86_64-linux, i686-linux, aarch64-linux and
armhf-linux).

As I've been developing it, I've been looking at various recent patch
series, and it seems like this is already useful. It's reassuring when
reviewing patches to see that packages still build on the architectures
being tested. Also, unlike earlier prototype patch testing setups,
because the builds are now happening on a default substitute server,
there should be some benefits already with substitutes being available
at the point the patches are merged.

This is very much still at the prototype stage though, many pages will
timeout or just fail to load due to an error.

Let me know if you have any comments or questions? If you want to try
and work on adding any features, I should also have time to try and help
out as well, so just let me know you're interested.

Thanks,

Chris


signature.asc
Description: PGP signature


What build system would be more appropriate for this application

2022-09-06 Thread Luis Felipe
Hi,

I'm packaging a Python application that doesn't have anything requiring 
compilation, it just needs copying files to the appropriate directories, so I 
started with the copy-build-system using an install-plan as follows:

~~~
(build-system copy-build-system)
(arguments
 `(#:install-plan
   `(("help/C/mazo" "share/help/C/")
 ("icons/mazo.svg" "share/icons/hicolor/scalable/apps/")
 ("mazo" "lib/python3.9/site-packages/")  ; FIXME: Use GUIX_PYTHONPATH
 ("lugare.ulkeva.Mazo.desktop" "share/applications/")
 ("mazo.py" "bin/mazo" ; TODO: Make executable
;; TODO: Run tests.
~~~

This way, the package builds and I'm able to run the application in a guix 
shell. However, as the comments above indicate, I'd like to

1. Indicate the destination for the "mazo" Python package using GUIX_PYTHONPATH 
instead of the hardcoded path.
2. Make sure the "bin/mazo" file is executable (the source, "mazo.py", is 
executable, though).
3. Run tests

Do you think I can achieve these sticking to the copy-build-system, or would it 
be necessary to resort to meson or similar build systems?

Thanks in advance,


---
Luis Felipe López Acevedo
https://luis-felipe.gitlab.io/

publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature