unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: Arun Isaac <arunisaac@systemreboot.net>
Cc: 32160@debbugs.gnu.org
Subject: bug#32160: auto compile fails to recompile when included source files change
Date: Thu, 02 Aug 2018 14:01:29 -0400	[thread overview]
Message-ID: <87muu4ve9y.fsf@netris.org> (raw)
In-Reply-To: <cu7in5hdyup.fsf@systemreboot.net> (Arun Isaac's message of "Sun,  15 Jul 2018 07:49:58 +0530")

Hi Arun,

Arun Isaac <arunisaac@systemreboot.net> writes:

> Guile's auto compile fails to recompile when included source files
> change.
>
> For example, I have two source files -- foo.scm and bar.scm. foo.scm
> includes bar.scm using `include'. When I run foo.scm for the first time,
> it is auto compiled and run correctly. But, if I modify bar.scm and run
> foo.scm again, foo.scm is not rebuilt and the old version is run.

Yes, this is a known limitation in Guile's auto-compilation support.
Unfortunately, we don't have any system in place to track these
dependencies between modules.  Years ago, I spent some time thinking
about how to do it, but it's nontrivial given the unstructured and
imperative model by which modules load themselves and their
dependencies.  The .go file format would also need to be extended to
embed the dependency information.

There's also the question of how to fingerprint the dependencies.  If
timestamps are used, it would defeat deterministic builds, but if hashes
are used, it might dramatically slow down module loading, especially
given that it would not be sufficient to check the immediate
dependencies: the full transitive closure of the module dependency graph
would need to be traversed.

And then there's the unfortunate fact that although circular module
dependencies are (sensibly) prohibited by standard Scheme and most other
languages, in Guile they are not prohibited, and although they cause a
great many headaches, they sort-of-work if you are lucky, and Guix now
depends heavily on them.  Last I checked, Guix has a large number of
package modules (well over 50, and possibly more than 100 at this point)
that form a strongly connected component in the module dependency graph.

I'm sorry that I don't have a better answer for you.  If you'd like to
investigate further, I'd be glad to give you pointers and advice, but
it's not a project for the faint-hearted :-/

      Regards,
        Mark





  reply	other threads:[~2018-08-02 18:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-15  2:19 bug#32160: auto compile fails to recompile when included source files change Arun Isaac
2018-08-02 18:01 ` Mark H Weaver [this message]
2018-08-02 18:52   ` Mark H Weaver
2018-08-02 21:01     ` Mark H Weaver
     [not found]   ` <20180802200226.GA12552@tuxteam.de>
2018-08-03  8:34     ` Arun Isaac
2018-08-03 16:34       ` Mark H Weaver

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://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87muu4ve9y.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=32160@debbugs.gnu.org \
    --cc=arunisaac@systemreboot.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.
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).