unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Zelphir Kaltstahl <zelphirkaltstahl@posteo.de>
To: Tim Van den Langenbergh <tmt_vdl@gmx.com>
Cc: guile-user@gnu.org
Subject: Re: guile-hall issues converting my project to a hall project
Date: Tue, 16 Feb 2021 01:23:34 +0100	[thread overview]
Message-ID: <b4a4a26f-2983-3ef3-7cbe-0ec940808565@posteo.de> (raw)
In-Reply-To: <2433258.t1ASBiXS4l@terra>

On 07.02.21 14:30, Tim Van den Langenbergh wrote:
> On Saturday, 6 February 2021 22:49:12 CET Zelphir Kaltstahl wrote:
>> Hello Guile Users!
>>
>> I decided to try to use guile-hall to convert my project at
>> https://notabug.org/ZelphirKaltstahl/guile-fslib into a Guix package.
>> For that purpose I created a separate branch
>> "wip-guix-package-using-guile-hall"
>> (branch: https://notabug.org/ZelphirKaltstahl/guile-fslib/src/wip-guix-packa
>> ge-using-guile-hall commit:
>> https://notabug.org/ZelphirKaltstahl/guile-fslib/src/a8344c5dd47515c533af3eb
>> d497adcce6b683e82), from which I am starting to run commands.
>>
>> It seems, that many of guile-hall's defaults are wrong for my project
>> and I need to adapt a lot of its settings. It also tells me to report
>> unsupported file types, but I cannot do that in the guile-hall
>> repository, because I cannot log in on Gitlab, because Gitlab has a
>> "clever" "check of my browser", which simply loops forever reloading the
>> "browser check" website … My guess: The check requires third party
>> cookies to be set. So I am going to write about it here and hope someone
>> knows how to proceed.
>>
>> The example call in the readme of
>> https://gitlab.com/a-sassmannshausen/guile-hall for converting a project is:
>>
>> ~~~~
>> hall init --convert --author "Jane Doe" --prefix guile frobnigator --execute
>> ~~~~
>>
>> I am not sure what exactly the prefix is. `hall init --help` only tells
>> me: "Prefix of the project.", which does not help me. It basically has
>> zero more information for me. Does this already have to do with the
>> Makefile, which is created later? I leave prefix at "guile" for now.
>> What is "frobnigator"? I think it is the name of the project, because in
>> `hall init --help` it says that the syntax is:
>>
>> ~~~~
>> hall initiate [-cx] NAME
>>                      [-a "Alyssa P. Hacker"]
>>                      [-l gpl3+]
>>                      [-p guile]
>>                      [-w "https://website.mine"]
>> ~~~~
>>
>> (I like the SICP reference, btw.) `NAME` is the only thing that I cannot
>> translate anything else to be in the command above. I think it would be
>> better to not use something confusing like "frobnigator", which people
>> might not know what that even is, and use a generic word like
>> "my-project-name".
>>
>> So the command I run is:
>>
>> ~~~~
>> hall init --convert --author 'Zelphir Kaltstahl' --prefix 'guile' fslib
>> --license 'agpl3+' --execute ~~~~
>>
>> What I like about it is, that everything seems to be dry-run, except
>> when adding `--execute`. That makes things less scary.
>>
>> Then hall creates a bunch of files, but most things seem not to consider
>> my actual already existing project structure. hall never asks me what my
>> test directory is or what file my license information is in. I think it
>> would be good to have those things available as command line arguments,
>> so that I do not need to fix things afterwards, which differ from the
>> defaults.
>>
>> I will list the things, that I need to change to correct values after
>> the hall command has finished and steps I am taking, from the
>> perspective of a first time user, because perhaps it can help improving
>> guile-hall:
>>
>> (1) Remove my old license file, which was not `COPYING` but `LICENSE`.
>> Here I do not really care about in which file it is. It would be great,
>> if hall asked me about the `LICENSE` file though. Perhaps a list of
>> common names of license files could be added to hall and it could check
>> for those?
>>
>> (2) In `guix.scm` the version is wrong. It should be `(version
>> "0.2.0")`, not `(version "0.1")`. The git repository already has a tag
>> `0.2.0`, but I think, that "0.1" is a default value, which is simply put
>> into `guix.scm`. Here a `--version` argument would be good to have, with
>> the default still being `0.1.0` or `0.1`. I think 3 parts is the better
>> choice, because it makes processing version numbers easier. Every
>> version number would have 3 parts. Always. And it could be made a list
>> of 3 symbols or even numbers as well. But if they are only numbers, one
>> could not have something like "rc" for release candidate or stuff like
>> that. Also not everyone might want to use version numbers like these. I
>> have seen projects using the date as version number.
>>
>> (3) After adapting the version number, the `source` has to be adapted as
>> well to reflect the change in version. At this point I get insecure
>> about the whole thing. "Will Guix be able to find this archive? Will it
>> look only for a version number consisting of 2 parts? Will anything
>> break later in the process, because I am not following the same
>> versioning syntax and have 3 parts instead of 2 parts written in the
>> string?"
>>
>> (4) In the `guix.scm` native inputs are defined. The concept of that is
>> very unclear in my mind. I read about that previously on the Guix pages,
>> but I already forgot again what native inputs are and how they differ
>> from inputs. Anyway, probably not so important right now. However, they
>> list "texinfo". My project does not make use of texinfo at all. But I am
>> insecure now about removing it. Perhaps hall will not be able to deal
>> with it, if I remove it, so I am leaving it there for now. Hopefully I
>> can remove it later and make my dependencies fewer (?).
>>
>> (5) In `hall.scm` the version is wrong as well. As in `guix.scm`, I
>> change it to the correct version.
>>
>> (6) Next is the `files` section. This one creates a lot of insecurity.
>> It says `(directory "fslib" ())`. I have not put my source files into a
>> directory `fslib`, but I had no chance to tell hall, that there is no
>> such thing beforehand. If I have to move all my source files, then I
>> also need to change all my imports! My source files are in the root
>> directory of the project. I've had no need so far to move them into a
>> subdirectory. I guess with all the project managing files hall created,
>> a subdirectory makes sense, but then I am changing my code to conform to
>> what hall wants the structure to be and I am not telling hall what kind
>> of structure my project has instead, to make it figure out how to write
>> the makefiles etc. So this is one of the points, where I think it would
>> be good to give hall an argument `--source-location '.'` or something
>> like that. I will try to adapt the configuration by changing the
>> `directory` to "." instead of "fslib". More insecurity: "Will hall be
>> able to work with that? Will it understand "."? Or will everything break?"
>>
>> (7) The tests directory is wrong. I have my tests in `test`, without the
>> plural "s". I will change the setting.
>>
>> (8) I do not have additional `programs` in this project. Can I simply
>> remove this entry from the hall settings? I better leave it in there,
>> hall might break, if unexpectedly that setting is missing.
>>
>> (9) I do not know what to do now, that hall has created all these files
>> and I have corrected some of the values in its settings. At this point I
>> am asking myself, whether I somehow need to generate any of the files
>> anew. But I find the `HACKING` file and see that in there it says I can
>> activate a Guix environment now, from the files hall produced:
>>
>> ~~~~
>> guix environment -l guix.scm
>> ~~~~
>>
>> And that still works, even though I changed stuff in there. Good!
>>
>> (10) Next comes the important step it seems:
>>
>> ~~~~
>> hall dist --execute && autoreconf -vif && ./configure && make check
>> ~~~~
>>
>> `hall dist`. According to `hall dist --help` it will create the build
>> system files, which I am guessing are all the files for GNU Automake and
>> GNU Make and so on.
>>
>> I forgot what autoreconf did again.
>>
>> `./configure` checks for stuff in my system to be available or not, to
>> reason about whether the thing will build or not and collect locations
>> of required binaries etc.
>>
>> `make check` probably runs my tests.
>>
>> Everything runs through, there is a lot of output. It only shows `GEN
>> fslib.go` though, none of the other modules are shown. Probably because
>> I have not run `hall scan` yet.
>>
>> (11) `hall scan`. This gets me to the first real error:
>>
>> ~~~~
>> $ hall scan
>>
>> Your project contains a file (traces.1) of a type that is not supported by
>> Hall yet. (unknown-file).  Please report this at our website
>> ~~~~
>>
>> OK I cannot do that, because Gitlab does not let me in. Fine, where is
>> that file? `find . -name 'traces.1'` reveals:
>> `./autom4te.cache/traces.1`. Why does it look into the cache it created
>> itself? I did never create the file and the folder it is in. Is there
>> some ignore file for hall, like `.gitignore`, where I need to add the
>> cache folder to? OK, it is a cache folder, so I will simply delete it
>> and run `hall scan` again.
>>
>> ~~~~
>> $ rm -rf autom4te.cache
>> $ hall scan
>>
>> Your project contains a file (pre-applypatch.sample) of a type that is not
>> supported by Hall yet. (unknown-file).  Please report this at our website
>> ~~~~
>>
>> Damn, another file it does not support! Where is it this time? Oh no …
>> It is inside `.git`! But why does it complain about that?! It is normal
>> to have the .git folder at the top level. I cannot remove that. Git hook
>> sample files are there by default. Perhaps I can remove the sample hook
>> files and then try again …
>>
>> … Now it complains about my tag files in .git! It seems I cannot run
>> `hall scan` successfully.
>>
>> This is it so far. This is as far as I got and I have no idea, whether I
>> am anywhere close to a functioning package.
>>
>> Can you help me out? How do I proceed from here? Please assume no
>> knowledge about "things that are obvious" about any of guile-hall or
>> autotools, automake, make and the like.
>>
>> Do I really have to move my source files into the directory hall created
>> and change all my import expressions in the source code? That can be
>> arranged. Although this seems to hint at an unfortunate coupling of
>> project name and directory in which source files reside. Similar to what
>> docker-compose is doing with container names and the folder inside which
>> you run it. Such a thing can be quite annoying.
>>
>> How do I fix that "unsupported file type" thing?
>>
>> I feel like there are so many files and stuff hall added, that if only I
>> understood more about what exactly GNU Guix _must_ find in the project
>> directory to use it as a package, I might be better off creating that
>> stuff manually, but perhaps to make a package I must have all this
>> stuff? I have no idea, whether the license must be in COPYING, or having
>> it inside LICENSE is fine too. I think I will ask for a complete list of
>> all things required by Guix on the Guix mailing list. The verdict is not
>> out yet though. I still hope to make everything work with guile-hall,
>> hoping anyone can help.
>>
>> Best regards,
>> Zelphir
> Hi Zelphir,
>
> the prefix is a part of the project name that you do not want to include in the 
> name of whichever module/library you are making, for example if I want to make 
> a project called "Guile-Utils" which exports a library called "utils" I would 
> use the prefix argument to add "guile" in front. Without it I could make a 
> library called "utils" but hall would complain if I didn't have a library 
> called "guile-utils" as well.
>
> You also raised various good points, especially about what a pain it is to run 
> hall scan after running hall dist (which we really should warn people not to 
> do).
>
> Basically the way to think of hall is like an inverse git, where instead of 
> excluding certain files with a .gitignore, you keep track of files through your 
> hall.scm.
>
> If you don't want to restart the conversion of your project to a hall project 
> from scratch I fear you may have to edit your hall.scm by hand.
>
> Feel free to contact me if you have more questions.
>
> Vale,
>
> -Tim Van den Langenbergh

Hello Tim and hello Guile users!

I finally got around to reproducing your patch step-by-step. I have
tried to make the commits as "atomic" as possible, so that one can see
each step I took in a separate commit. The result is here:
https://notabug.org/ZelphirKaltstahl/guile-fslib/src/65d40a0f1dd4bb2005d3f369928ebf5b2247eacc.
Now however, I am hitting an issue. When I run:

~~~~
hall dist --execute && autoreconf -vif && ./configure && make check
~~~~

as indicated in the autogenerated HACKING file, I get an error deep in
the generated `configure` file:

~~~~
$ hall dist --execute && autoreconf -vif && ./configure && make check
Making file: /home/user/dev/Guile/guile-fslib/NEWS
Making file: /home/user/dev/Guile/guile-fslib/AUTHORS
Making file: /home/user/dev/Guile/guile-fslib/ChangeLog
Making dir: /home/user/dev/Guile/guile-fslib/build-aux
  Making file: /home/user/dev/Guile/guile-fslib/build-aux/test-driver.scm
Making file: /home/user/dev/Guile/guile-fslib/configure.ac
Making file: /home/user/dev/Guile/guile-fslib/Makefile.am
Making file: /home/user/dev/Guile/guile-fslib/pre-inst-env.in
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
aclocal: warning: couldn't open directory 'm4': No such file or directory
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf --force
autoreconf: configure.ac: not using Autoheader
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:11: installing 'build-aux/install-sh'
configure.ac:11: installing 'build-aux/missing'
Makefile.am: installing './INSTALL'
Makefile.am: installing './COPYING' using GNU General Public License v3 file
Makefile.am:     Consider adding the COPYING file to the version control system
Makefile.am:     for your code, to avoid questions about which license your project uses
Makefile.am:62: installing 'build-aux/mdate-sh'
Makefile.am:62: installing 'build-aux/texinfo.tex'
Makefile.am:63: warning: user target 'dvi' defined here ...
automake: ... overrides Automake target 'dvi' defined here
Makefile.am:63: consider using dvi-local instead of dvi
autoreconf: Leaving directory `.'
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
./configure: line 2385: syntax error near unexpected token `3.0'
./configure: line 2385: `GUILE_PKG(3.0 2.2 2.0)'
~~~~

The line in the generated `configure` file looks quite simple. It is only:

~~~~
GUILE_PKG(3.0 2.2 2.0)
~~~~

It looks like there could be a simple fix, but I do not know what to do
about this error and how that error could happen in the first place.

To be sure I also tried the same with your patch applied to the commit,
where I had not yet done any steps with guile-hall, but the result and
error remains the same.

How can I fix this error?

Best regards,
Zelphir

-- 
repositories: https://notabug.org/ZelphirKaltstahl



  parent reply	other threads:[~2021-02-16  0:23 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-06 21:49 guile-hall issues converting my project to a hall project Zelphir Kaltstahl
2021-02-07  9:14 ` tomas
2021-02-07 13:30 ` Tim Van den Langenbergh
2021-02-11 20:30   ` Zelphir Kaltstahl
2021-02-16  0:23   ` Zelphir Kaltstahl [this message]
2021-02-17 22:47     ` Vladimir Zhbanov
2021-02-18 12:18       ` alex sassmannshausen
     [not found] ` <11206998.46ALo4VoAQ@terra>
     [not found]   ` <02902ff9-1585-a453-4e36-c9a731eee6fe@posteo.de>
2021-02-16 16:48     ` Tim Van den Langenbergh
2021-02-16 18:12       ` Zelphir Kaltstahl
2021-02-17 21:17         ` Alex Sassmannshausen
2021-02-18 19:16           ` Zelphir Kaltstahl
2021-02-21 13:42             ` Alex Sassmannshausen
2021-02-22 11:34               ` guile-hall packaging guide Zelphir Kaltstahl
2021-02-22 20:52                 ` Jérémy Korwin-Zmijowski
2021-02-23 16:32                   ` Alex Sassmannshausen

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=b4a4a26f-2983-3ef3-7cbe-0ec940808565@posteo.de \
    --to=zelphirkaltstahl@posteo.de \
    --cc=guile-user@gnu.org \
    --cc=tmt_vdl@gmx.com \
    /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).