From: "Ludovic Courtès" <ludo@gnu.org>
To: Robert Vollmert <rob@vllmrt.net>
Cc: 36511@debbugs.gnu.org
Subject: bug#36511: extraneous recompiles of scm files while editing gnu/packages/
Date: Mon, 08 Jul 2019 12:03:59 +0200 [thread overview]
Message-ID: <878st8g7w0.fsf@gnu.org> (raw)
In-Reply-To: <E0B2EBE5-450A-407D-BD52-0A57A8B1DF4A@vllmrt.net> (Robert Vollmert's message of "Mon, 8 Jul 2019 09:50:21 +0200")
Robert Vollmert <rob@vllmrt.net> skribis:
>> On 5. Jul 2019, at 22:40, Ludovic Courtès <ludo@gnu.org> wrote:
>>
>> Hi,
>>
>> Robert Vollmert <rob@vllmrt.net> skribis:
>>
>>> rob@garp ~/guix$ nano gnu/packages/haskell.scm
>>> rob@garp ~/guix$ ./pre-inst-env guix build ghc-ansi-wl-pprint
>>
>> I’d suggest running “make” once you’ve edited a file.
>>
>> It’s not strictly necessary (Guile then simply evaluates code instead of
>> running compiled code), but it will allow you to get rid of these
>> warnings, the compiler might warn you ahead of time of possible
>> mistakes, and the whole thing will be slightly faster.
>>
>> Does that make sense?
>
> It does make sense. However once again my complaint is a bit more about the
> developer experience than how to work around the current state. I feel that
> a situation where the obvious thing works but is painful (guile debug spam,
> slowness) and you need to learn to do things differently (always run make first,
> which frequently causes work you don’t even care about, such as a guix-daemon
> recompile or po-file work) could be improved upon.
Yes I agree. Things to have to be compiled at one point though. We
could let Guile auto-compile code, but unfortunately that comes with its
own warts: the equivalent of “make clean-go”, for instance when an ABI
incompatibility pops up, is “rm -rf ~/.cache/guile/ccache”, and that too
is something a developer has too learn, and one could argue that it’s
less familiar than “make” or “make clean.”
So, I’m not satisfied with the ./pre-inst-env and ‘make’ workflow, but
we have yet to come up with a concrete proposal for a better workflow.
> Concretely, this bug report is in response to
> https://lists.gnu.org/archive/html/guix-devel/2019-07/msg00009.html
>
> In that spirit, “you should run make first” is not answer I’m completely
> happy with. :)
I was trying to address the “I see recompilation messages” issue that
you raised in the current framework. I didn’t initially interpret the
bug report as a call for a new workflow.
Thanks,
Ludo’.
next prev parent reply other threads:[~2019-07-08 10:05 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-05 14:22 bug#36511: extraneous recompiles of scm files while editing gnu/packages/ Robert Vollmert
2019-07-05 20:40 ` Ludovic Courtès
2019-07-08 7:50 ` Robert Vollmert
2019-07-08 10:03 ` Ludovic Courtès [this message]
2019-07-08 11:46 ` Robert Vollmert
2019-07-08 22:15 ` Ludovic Courtès
2019-07-09 15:45 ` Robert Vollmert
2019-07-12 7:40 ` Robert Vollmert
2019-07-13 8:33 ` Ludovic Courtès
2019-07-12 7:38 ` Robert Vollmert
2019-07-12 20:50 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878st8g7w0.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=36511@debbugs.gnu.org \
--cc=rob@vllmrt.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).