From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Zelphir Kaltstahl Newsgroups: gmane.lisp.guile.user Subject: Re: guile-hall issues converting my project to a hall project Date: Tue, 16 Feb 2021 01:23:34 +0100 Message-ID: References: <2433258.t1ASBiXS4l@terra> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35040"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Icedove/68.10.0 Cc: guile-user@gnu.org To: Tim Van den Langenbergh Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Tue Feb 16 01:23:57 2021 Return-path: Envelope-to: guile-user@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lBo9k-000911-Qa for guile-user@m.gmane-mx.org; Tue, 16 Feb 2021 01:23:57 +0100 Original-Received: from localhost ([::1]:33614 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lBo9j-0001vq-SW for guile-user@m.gmane-mx.org; Mon, 15 Feb 2021 19:23:55 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55602) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lBo9Z-0001ve-3Z for guile-user@gnu.org; Mon, 15 Feb 2021 19:23:45 -0500 Original-Received: from mout01.posteo.de ([185.67.36.65]:56686) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lBo9U-0001os-QY for guile-user@gnu.org; Mon, 15 Feb 2021 19:23:44 -0500 Original-Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id 8311416005C for ; Tue, 16 Feb 2021 01:23:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1613435016; bh=j0/zLDi6JzbYr89Bc1Ly68aKtXdDn98itHRYaczYau0=; h=Subject:To:Cc:From:Date:From; b=NJqo+lcal8gLTij8fJRfudMWtp3EJADF2eUfPEgzIq0FZ5dBX1RCgNiLyRrtn90jZ jGsDCpTpnoPNCsv9zpoibCsKr1gthI98xLB+GYK6kyqwMvVDngrlbUzJFGoMPqeS/B RYxHq+PsNy2phwADX3jgvqfYI8o6I2kS1ro/x1OG89KdpYYPEIPClXKBpcp8R2tikE p6DOozdZpT6H8dfnEhtI3gwoT4uyDFpD6vxgxD3au4UJPg58SbZRPYDeKyArPchcTb gjD2aLXLpYct/pVzjNTMTW6jRjPfXa7z9nzo4jrFjbRG3EubrPeIiUV0evm+L/6kYm K9RAPKGs5XP2Q== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4DfhXR3QVzz6tm9; Tue, 16 Feb 2021 01:23:35 +0100 (CET) In-Reply-To: <2433258.t1ASBiXS4l@terra> Content-Language: en-US Received-SPF: pass client-ip=185.67.36.65; envelope-from=zelphirkaltstahl@posteo.de; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.io gmane.lisp.guile.user:17253 Archived-At: 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