Re: On a Guile-based Build-Tool complimenting Guix

[Pjotr Prins]

On Sat, Dec 28, 2024 at 01:48:02AM +0000, Divya Ranjan wrote:
>    Hello Pjotr, glad to see that you'd be still interested in such a
>    project.
>    > Where it comes to other targets, such as Debian distros and all, it
>    is probably going to be too painful to handle to resolve all their
>    demands.
>    Can you elaborate on what exactly would be hard to figure out for a
>    Debian target?

Probably an idea to package some things for Debian, or study those?
It'll give a clear picture :). From my point of view these packagers
are pretty heroic.  Even my software gets quite a few Debian patches
to make it work.  Build systems go some way towards helping distros.

I think it gets most hairy when dependencies have to be addressed for
software that does not use pkg-config, for example. It is a mad world
out there (outside Guix ;). Also think conda etc. A clean build for
Debian an conda would be a great lithmus test.

>    And, I personally think just generating makefiles in Guile isn't really
>    going to be better. I mean it'll save someone from writing a Makefile
>    in, well, Make, but it will still have the issues of `make`. I believe
>    it is an alternate build system that we should try.

Sure, it may be worth creating a clean system. But I do note that both
meson and cmake chose to handle the build through make or ninja. There
must be a reason for that :)

Debian packagers tend to prefer meson, make and cmake (I don't know in
what order of preference).

Wrt supporting other distros outside guix - the reality is that
software authors need to distribute software. They will only adopt a
build system if it allows targeting those too. 

My simple needs as a software developer of tools that run everywhere are:

1- Clean and *fast* development build system on Guix
2- Allow generating reasonably clean builds for Debian, Conda etc.
3- Allow multi-language builds (think guile+zig or python+C++)

Maybe what you have in mind will cut it, I don't know. Maybe it is
good enough to target (1) and (3). But to replace meson and cmake you'd
need (2). 

Anyway, my 2cts. It is just an old train of thought. Start simple.
I'll definitely try your work if you come up with something that cuts
(1) and (3). Without (2) I'll probably still end up adding cmake for
distribution. 

When I was thinking about these ideas years ago I was thinking that
something that generates cmake in addition to compiling directly would
be quite a win. I really don't like cmake, but for now we have nothing
better. I have not been impressed by meson either. Generating make
instead of cmake will be much simpler, maybe easier, and probably cut
it too.

Pj.