| Message ID | 20200521005046.19712-1-rprior@protonmail.com |
|---|---|
| Headers | show |
Hi Ryan, Ryan Prior <rprior@protonmail.com> skribis: > As an end-user, I want to create a manifest that to hack on some code where > the upstream build system badly wants to use `cc' and provides no practical > way to avoid this. At present, I have to create symlinks myself or patch the > build system; either way is non-obvious to other people who might try and use > my manifest when I share it. > > With this patch in Guix I can just specify `gcc-toolchain-wrapper' in my > manifest and have that be the end of it. For consistency's sake I have applied > this to all other c compilers I could find in Guix as well. A long time ago, we decided against it, which is not to say that this is set in stone but at least there’s a discussion to be had. :-) For packages, the workaround usually boils down to setting shell or Makefile variable ‘CC’ to “gcc” or similar. As for users, they can have a shell alias. In a nutshell, the reasons to not have a ‘cc’ program are that (1) it’s easily worked around, and (2) our guideline is to follow what upstream does, and none of these compilers provides a ‘cc’ program. (There are threads in the mailing list archives discussing this.) I’m personally in favor of the status quo on this topic. Thoughts? Thanks, Ludo’.
On Friday, May 22, 2020 9:42 AM, Ludovic Courtès <ludo@gnu.org> wrote: > For packages, the workaround usually boils down to setting shell or Makefile variable ‘CC’ to “gcc” or similar. Agreed, packages have what they need already. > As for users, they can have a shell alias. At present, there's no way to specify a shell alias as part of an environment/profile manifest. These patches would fill that gap for this narrow use-case, as the `python-wrapper` package fills it for another narrow use case. > it’s easily worked around Fair. > our guideline is to follow what upstream does, and none of these compilers provides a ‘cc’ program. (There are > threads in the mailing list archives discussing this.) I find this persuasive locally, but in a global sense it results in a less compelling end-user experience which outweighs my partiality towards this guideline. > I’m personally in favor of the status quo on this topic. Thank you for weighing in! My use-case, my vision, is that I want to provide end-users an environment manifest such that `guix environment -m build-env.scm` sets everything up so that `make && make check` succeed. I created these wrappers in service of this vision, to save end-users the trouble of creating and managing aliases on a per-environment basis when they already don't have to do that using the working set they're familiar with. I want to position Guix as a total win for tooling simplicity; but a lot of small complexities, each of which is easily worked-around, add up quickly to undermine my message. I would lose all interest in this patch set if I had a more general purpose way of extending a manifest with more things than just packages. I picture, for example, a manifest with three parts: - packages - env variables - aliases Right now afaict a manifest only has the first of those things. Given I've got this nice packagehammer, I'm inclined to insist upon the usefulness of this patch set as a means of turning `cc` into a nail. But I'd be happier to use a better tool anyhow. What do y'all guix think is the best pattern to apply for my use case? Sincerely, Ryan
Hi, Ryan Prior <rprior@protonmail.com> skribis: > My use-case, my vision, is that I want to provide end-users an environment manifest such that `guix environment -m build-env.scm` sets everything up so that `make && make check` succeed. > > I created these wrappers in service of this vision, to save end-users the trouble of creating and managing aliases on a per-environment basis when they already don't have to do that using the working set they're familiar with. I want to position Guix as a total win for tooling simplicity; but a lot of small complexities, each of which is easily worked-around, add up quickly to undermine my message. > > I would lose all interest in this patch set if I had a more general purpose way of extending a manifest with more things than just packages. I picture, for example, a manifest with three parts: > > - packages > - env variables > - aliases > > Right now afaict a manifest only has the first of those things. Given I've got this nice packagehammer, I'm inclined to insist upon the usefulness of this patch set as a means of turning `cc` into a nail. I understand your goal and I agree that it’s good to avoid building a pile of small complexities that all add up. I don’t think lack of ‘cc’ is one them though. First, because it’s a developer tool, and developers will know they can type ‘gcc’, ‘clang’, or whatever, create an alias, etc. Second, because most build systems (Autoconf-generated ‘configure’ scripts, CMake) accommodate the lack of ‘cc’, which thus goes unnoticed. My 2¢! Ludo’.