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: guile-hall issues converting my project to a hall project Date: Sat, 6 Feb 2021 22:49:12 +0100 Message-ID: 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="40174"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 To: Guile User Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Sat Feb 06 22:49:33 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 1l8VSN-000ALo-Vx for guile-user@m.gmane-mx.org; Sat, 06 Feb 2021 22:49:32 +0100 Original-Received: from localhost ([::1]:38060 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l8VSN-0003gG-2j for guile-user@m.gmane-mx.org; Sat, 06 Feb 2021 16:49:31 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51680) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l8VSD-0003g8-37 for guile-user@gnu.org; Sat, 06 Feb 2021 16:49:21 -0500 Original-Received: from mout01.posteo.de ([185.67.36.65]:49880) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l8VSA-0000xu-3H for guile-user@gnu.org; Sat, 06 Feb 2021 16:49:20 -0500 Original-Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id 7676616005C for ; Sat, 6 Feb 2021 22:49:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1612648154; bh=wPbyjToBQaSJCMllZqKtUEy27NMaqOY6+Y60UoGgXc4=; h=To:From:Subject:Date:From; b=RFhAGU3W52HTFyqv7j0mK/0weqzlALQjkGTbbCYnke0jfXsHbr6wxqRQiMcizQoL2 +yY0hIUFvfu/JJEUu/hqklS/Kp86+3FI919o39hLKaYAOdUHKeWvsBXJC2mlA/M7JX koqwyUOFabQKTnNkNjIbFdirmwx1Tz9GhcgDNN3bWM2gfpu/wGhgl5Xa72tQeM27r0 kNT+Jgy92QXpDFIfHJi1dnOzlj0mgTx63Vo0SzrUBLKGq7yZNisSq1Ek/oxp5jMC2Z /OFIdFZR4+UCFmB45n7F9baVurJuKmKoA97w8XTIYwmlp+dG9Tlj2JMciAiZ+XiIQk CHSgDviwKAQQQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4DY5XT10cHz6tmR for ; Sat, 6 Feb 2021 22:49:12 +0100 (CET) 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, 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-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:17229 Archived-At: 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-package-using-guile-hall commit: https://notabug.org/ZelphirKaltstahl/guile-fslib/src/a8344c5dd47515c533af3ebd497adcce6b683e82), 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 -- repositories: https://notabug.org/ZelphirKaltstahl