Thanks for the work! I'd like to use it in my next project, and introduce it in my new book.
Best regards. On Sat, May 16, 2020, 23:42 Alex Sassmannshausen < alex.sassmannshau...@gmail.com> wrote: > Hello, > > I have the pleasure to announce that I have today released Guile Hall > 0.3.0. > > You can get a tarball (that requires autoreconf) at > https://gitlab.com/a-sassmannshausen/guile-hall/-/releases. > > You can also install it with the latest Guix (from a3dfe05285): > $ guix install guile-hall > > You can check the source code, and report issues at > https://gitlab.com/a-sassmannshausen/guile-hall/. > > I would like to thank the following people, who have all contributed > issues, thougts or code. > > Stephen Scheck <singularsyn...@gmail.com> > Jose A. Ortega Ruiz <j...@gnu.org> > Jack Hill <jackh...@jackhill.us> > Adriano Peluso <caton...@gmail.com> > > Release notes below, under * Changes in 0.3 (since 0.2.1). > > * From the README file > > Hall aims to provide a black box that "just works" (tm), so that you > can create, develop, build & distribute Guile projects. > > With Hall you will be able to: > - Manage a Guile project hierarchy from one project spec file. > - Transparently support the GNU build system for maximum portability. > - Leverage tight coupling to Guix for reliability & confidence. > - Profit. > > This README is all written documentation that currently exists. The > project must be considered Alpha software at this stage. > > Nonetheless, all commands and arguments are documented, and passing > the -h flag to any command or sub-command should provide you with some > guidance. In addition all procedures in the codebase are documented > with docstrings. > > * Changes in 0.3 (since 0.2.1) > > ** Allow adding single files to hall.scm using `hall scan' > > `hall scan' now accepts two optional arguments so that you can quickly > add > individual files to your hall.scm file, even if your project state is > dirty. This is an alternative to running the full auto-magic `hall > scan' > command. > > ** Emit user friendly error messages for common failures > > Hitherto we simply used `throw' to error out of unexpected situations. > This would happen even in the case of user error or predictable > situations. > > I consider the codebase solid enough to emit more user-friendly error > messages in predictable situations. > > ** Allow use of fully-fledged regexp to --skip files > > The `scan' and `clean' subcommands accept a --skip keyword to exclude > specific (classes of) files from their operation. So far they had to be > precise files. The --skip keyword now expects Guile style regex pattern > strings for increased flexibility. > > ** Add a notes system for giving advice to the user > > Hall aims to understand your project and the files it contains, even if > it > does not fully support your use case. To this end, its architecture > creates a representation of your project in the hall.scm file. > > Hall now has a facility for emitting useful commentary when creating or > manipulating this representation. > > A current case in point at present is that we understand that Guile > projects may include C files — but Hall does not support them in its > build > infrastructure. So we want to allow & support users who include C > files, > but we want to warn them about Hall's short-comings in this area. > > ** Change the filetype architecture > > So far, filetype registration code was spread out over the codebase. > From > this version we support a simple <filetype> interface. Supported > filetypes > are declared in /hall/spec.scm. > > Supporting more filetypes is as easy as adding a simple declaration > there. > > This sets up a further development allowing individual projects to > specify > filetypes above and beyond Hall's built-in filetypes. > > ** Support XML, C, .log, .trs, .tex, & emacs autosave/backup files > > A simple development thanks to the above. > > ** Add a default .gitignore file > > Hall has strong opinions about development, primarily to stop new > developers from having to make bewildering choices. Currently it pushes > strong git & guix integration, as well as a specific documentation and > folder structure. As such we now add a standard .gitignore file that > should cover the vast majority of use cases. > >