
Code Staging in GNU Guix - Fice
https://hal.inria.fr/hal-01580582/en
======
ZenoArrow
Another explanation of g-expressions can be found here:

[https://www.gnu.org/software/guix/manual/html_node/G_002dExp...](https://www.gnu.org/software/guix/manual/html_node/G_002dExpressions.html)

I don't know if it's just me, but a lot of build systems just seem
unnecessarily complicated. I don't understand why it's necessary to have any
more features than a templating language would provide. So for example, set up
a template for each compiler with default values, allow the user to override
the default values, and throw an exception if builds fail.

~~~
taeric
I hate to ask, but have you actually checked what the extra features are?
There is a solid chance that the folks working on this are hitting real use
cases.

Offhand, in this case in particular, it is probably to provide dependency
isolation of things that you are building. Some things work as global to the
computer dependencies. Some do not.

As for why give the flexibility allowed with a full language? In large, so
that users are not constrained by the single vendor of the templates. You
could have multiple vendors of the templates, of course, but I suspect you
will find that immediately everyone is encouraged to self vend their own. In
which case, few would ever actually talk about the templates, but the language
the templates are written in.

~~~
ZenoArrow
My question was and is, why is there so much complexity? If there are valid
reasons, then fine, but from what I'm looking at a lot of it seems
unnecessary.

At its core, what is a build system meant to do? Build packages based on set
configurations, right? In other words:

1\. Set compiler flags.

2\. Define/include/build dependencies.

3\. Set build paths.

4\. Build and test packages.

All of the required steps can be managed manually via the command line, and at
its core a build system is just a way to automate this work. Why are other
command-line tasks so much simpler to automate than package compilation?
That's what I want to know.

~~~
di4na
How do you setup the rest of dependencies configuration ? How do you know that
there are no hidden dependencies ? How do you handle time ? How do you ensure
that it can be reproduce ? How do you define the dependencies ? How do you
make sure that nothing change the build paths ? The deps paths ? That your
environment is exactly the one you want ? That you dynamicly link to the
correct lib ? And let's not talk about cross compilation.

Also how do you clean behind yourself ?

Same thing for testing with even more setup.

~~~
ZenoArrow
> "How do you setup the rest of dependencies configuration ? How do you know
> that there are no hidden dependencies ?"

Each dependency has its own build configuration file. You build a tree of
dependencies and start compilation from the lowest level (i.e. the build
objects without any non-compiled dependencies).

With such an approach, why would you have a hidden dependency?

> "How do you handle time ?"

What do you mean by this?

> "How do you ensure that it can be reproduce ?"

Semantic version control on the dependencies.

> "How do you define the dependencies ?"

Is this a hard problem?

> "How do you make sure that nothing change the build paths ? The deps paths ?
> That your environment is exactly the one you want ?"

By testing during the build process. In the case of the environment, it's just
a question of checking against a list of expected environment settings (e.g.
OS version, processor architecture, processor features, etc...).

> "That you dynamicly link to the correct lib ?"

This comes down to version control.

> "Also how do you clean behind yourself ?"

Again, is this a hard problem? Even the simplest of makefiles can describe how
to handle this.

Perhaps it's best to give a concrete example of a task which is hard for a
build system to manage, because I'm still not seeing the complexity here.

~~~
benley
There have been a bunch of papers published discussing these topics at great
length, and many attempts at producing simpler systems that still work at non-
trivial scales. I'd suggest taking a look at
[https://nixos.org/~eelco/pubs/phd-
thesis.pdf](https://nixos.org/~eelco/pubs/phd-thesis.pdf) and/or
[https://nixos.org/~eelco/pubs/nspfssd-
lisa2004-final.pdf](https://nixos.org/~eelco/pubs/nspfssd-lisa2004-final.pdf)
for an overview of the origins of Guix and the reasoning behind its apparent
complexity.

~~~
ZenoArrow
Thank you. That's all I was looking for.

~~~
gnufx
Looking in the paper at issue and the Guix web site might have helped.

