guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Recommended project structure


From: wolf
Subject: Re: Recommended project structure
Date: Fri, 9 Jun 2023 14:55:42 +0200

On 2023-06-08 23:33:47 -0400, Olivier Dion wrote:
> On Fri, 09 Jun 2023, wolf <wolf@wolfsden.cz> wrote:
> > Greetings,
> >
> > I am starting a small, personal project and I want to write it in GNU Guile,
> > since I really like it so far.  However, since one of the major goals is for
> > this to be a learning experience and doing it "the right way", I wanted to 
> > ask
> > about recommended/standard project structure for Guile projects.  I found
> > this[0] tutorial, but it is from 2017, which is quite some time back (I feel
> > old).
> 
> Actually, what I like about Guile, there is no "the right way" like in
> Python.  Whatever is best for the developers is the right way, not some
> weird standard made by people with their view of the world.
> 
> Anyhow, if you're looking for a common structure, it is actually
> simple.  The root of your project acts like a load path.  So say you
> have two modules.  (foo) and (foo fuz), then you will have foo.scm for
> (foo) and foo/fuz.scm for (foo fuz).
> 
> If you don't like having source files in the root directory
> (i.e. foo.scm), then simply consider a sub-directory of your project as
> the load path for Guile.  For example you could have everything under
> src/.  Therefore, src/foo.scm for (foo) and src/foo/fuz.scm for (foo
> fuz).  However, this kind of break the magic for me.
> 
> Following this, you can then easily configure Geiser in Emacs to add
> the root of your project (or sub-directory) to Guile load path.
> Everything is natural that way.
> 
> What is nice about this structure is that you can have helper modules
> that are not meant for user.  I have for example a scripts/, tests/ and
> tools/ directories in my projects.  That way I can start a REPL and
> use-module my tools/ (debugging, plotting, etc.) or execute a scripts/
> (running tests, benchmarks, etc.).  Everything can be done in the REPL!
> 
> Note that this structure require a little more work when you're doing
> out of tree build, e.g. with autotools.  But for a small Guile project,
> that should not be a problem.

Ah, thank you for the write up.  It is very useful to know how someone actually
does it in practice.  Especially the ease of using REPL in this setup.

In general like autotools, so I will probably try to incorporate them somehow.

> 
> > So I wanted to ask, does the tutorial describe best practices even in 2023? 
> >  If
> > not, what would be a good reading on this topic?
> 
> I do not see any link in your message so I can not say.

That is pretty embarrassing mistake on my part, the link is:
https://www.erikedrosa.com/2017/10/29/guile-projects-with-autotools.html .

> 
> -- 
> Olivier Dion
> oldiob.dev

W.

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]