<mark_weaver>rigelk: sounds like you're trying to import (gnu packages gnu-make) from somewhere, but that module doesn't exist.
<rigelk>mark_weaver: i still try to understand how the whole thing works ^^' so to be know to guix, a package has to have a .scm, a line in gnu-system.am and then a .go generated through `make sync-descriptions` ?
<mark_weaver>more than one package can exist in a module. each module has a .scm file.
<mark_weaver>I wouldn't worry about sync-descriptions for now. first get your package working to build it.
<mark_weaver>you don't need the line in gnu-system.am at first either, or the .go file.
<rigelk>davexunit: true. make output the same error : `In procedure scm_i_lreadparen: gnu/packages/doxygen.scm:58:1: end of file`
<mark_weaver>the line in gnu-system.am is needed to ensure that the module is automatically included in the guix release tarball, and installed when running "make install" in the guix build directory, etc.
<mark_weaver>but when you're first working on a package, all you need is the *.scm file in gnu/packages/
<mark_weaver>rigelk: sounds like your parens are mismatched or there's a syntax error in the file.
<mark_weaver>btw, for the sake of supporting cross-compilation, there's a distinction between 'inputs' and 'native-inputs', depending on whether the package will be run at package-build-time or run-time.
<mark_weaver>'make' is in the default set of native-inputs, fwiw, so it probably doesn't need to be explicitly specified.
<mark_weaver>(unless doxygen uses 'make' when the program is run by the user)
<rigelk>mark_weaver: i'm gonna check that, but imho doxygen doesn't use make.
<rigelk>is there any documentation concerning the different kinds of inputs ?
<mark_weaver>mst: I'm sorry, I don't really understand a lot of what you wrote there. I think you're assuming that I'm familiar with some other distro that has channels, and I don't have the needed knowledge to fill in the rest.
<mst>I thought 'channel' was the nix term and had been adopted by guix
<mark_weaver>but in guix, inputs are specified not against a package name, but rather a package object.
<mark_weaver>oh, possibly so. I'm not very familiar with nix, I confess :)
<mark_weaver>(I probably would be using it by now, if guix hadn't come along)
<mst>I've read all of the papers published by the authors; I considered that to be basic research before looking at guix lest I make a fool of myself with the questions I asked
<mst>apparently I've instead made a fool of myself by assuming the knowledge from there :D
<mst>my interest here is achieving uniform, robust deployment of applications
<mst>some of those applications will be proprietary
<mst>since I only consult under a contract that allows me to contribute back to the relevant open source projects anything that is *not* considered by the customer to be part of their 'secret sauce', I've no problem with them paying me to fix the open source stuff until it can handle their use case
<mst>but that means that *I* have to care about non-free software with politics, asshole maintainers and limited available time
<mst>and the free-ness of guix-the-base-distro doesn't change that, sadly
<mst>does anybody actually care about the build system itself, or only the OS?
<mark_weaver>I think we care about the build system, yes, but I don't think we plan to support as diverse a set of host OSes as you have in mind.
<mark_weaver>My understanding is that Guix is specifically targetting GNU systems, and I don't think we plan to expend much (if any) effort trying to make it portable to other systems. But maybe I'm wrong. Better to ask on guix-devel. I really feel that I'm not in a position to answer all of your questions.
<mst>to be honest, the fact that the inputs are evaluated when the .scm module is loaded suggests that it's probably too late to make guix capable of doing the things I want without radically re-architecting it
<mst>it seems to be just as un-dynamic as nix on that front
<mark_weaver>if I were you, I'd come up with a list of your requirements, and post them to guix-devel, and someone more knowledgeable than me can determine whether Guix is a good fit for your use case.
<mark_weaver>mst: packages are dynamic objects, they can be created dynamically.
<mst>if you were me, you wouldn't have a working mail setup for handling lists either and would be under your desk screaming at the thought of subscribing to another one
<rigelk>could someone give me an hint about how to test any further my package definition ? The syntax has been checked and the .go file generated. Next step should be to build, right ? any ideas on how to build ? -> at the moment it tells me it's an unknown package.
<mark_weaver>for example, instead of simply having a static top-level package definitoin, you can have a procedure that takes some parameters and dynamically generates a package object.
<mark_weaver>and then you can have other packages that call these procedures to generate the input packages.
<davexunit>rigelk: paste the module and I'll take a look
<mark_weaver>but so far, there are two things that aren't properly authenticated: guix pull, and binary substitutes. so I don't do either of those.
<mark_weaver>other things that are downloaded are verified against SHA256 hashes that are included in the guix git repo and tarballs.
<rigelk>mark_weaver: how do you compile not to spend hours a day compiling ? ^^'
<mark_weaver>rigelk: well, the bulk of it only has to be done every few months, when the "core-updates" branch is merged into the master branch, with new toolchain and core stuff.
<mark_weaver>once you have the C library, GCC, binutils, etc, bootstrapped, then all of that will be cached and you won't have to build them again very often.
<mark_weaver>and of course, once hydra is back up, you can use the binary substitutes if you like.
<mark_weaver>(hydra being our build farm and binary distribution mechanism)
<mark_weaver>just beware of "guix gc", which by default will delete all that stuff you needed to build things. that command needs a new mode for people who prefer to avoid substitutes (people like me :)
<rigelk>anyway, it reminds me of my old gentoo install :] good times.