Support lisp implementations other than ECL

[VisenDev]

Most ecl-specific calls could be trivially replaced with uiop calls, and given that asdf is already a dependency, this doesn't add any additional dependencies (uiop is part of asdf)

The ecl specific command line arguments parser has been replaced with a simple manual parser. This may require a little bit of testing, as I wasn't sure exactly what each of the sub-commands were intended to do because I could not get the ecl version to compile on my machine (which was one of my motivations for this port)

robertb@nobara-pc ~/c/vend (portability)> make
ecl --load build.lisp
;;; Loading #P"/home/robertb/common-lisp/vend/build.lisp"
;;; Loading #P"/usr/local/lib/ecl-24.5.10/asdf.fas"
--- LOADING SYSTEM ---
--- COMPILING EXECUTABLE ---
;;;
;;; Compiling /home/robertb/common-lisp/vend/vendored/filepaths/src/filepaths.lisp.
;;; OPTIMIZE levels: Safety=1, Space=0, Speed=3, Debug=1
;;;
;;; Internal error:
;;;   ** Error code 1 when executing
;;; (EXT:RUN-PROGRAM "gcc" ("-I." "-I/usr/local/include/" "-D_GNU_SOURCE" "-D_FILE_OFFSET_BITS=64" "-g" "-O2" "-fPIC" "-D_THREAD_SAFE" "-Dlinux" "-O2" "-c" "/home/robertb/.cache/common-lisp/ecl-24.5.10-7b546e7f-linux-x64/home/robertb/common-lisp/vend/vendored/filepaths/src/filepaths.c" "-o" "/home/robertb/.cache/common-lisp/ecl-24.5.10-7b546e7f-linux-x64/home/robertb/common-lisp/vend/vendored/filepaths/src/filepaths.o")):
;;; In file included from /usr/local/include/ecl/ecl.h:81,
;;;                  from /usr/local/include/ecl/ecl-cmp.h:31,
;;;                  from /home/robertb/.cache/common-lisp/ecl-24.5.10-7b546e7f-linux-x64/home/robertb/common-lisp/vend/vendored/filepaths/src/filepaths.c:5:
;;; /usr/local/include/ecl/object.h:27:13: error: ‘bool’ cannot be defined via ‘typedef’
;;;    27 | typedef int bool;
;;;       |             ^~~~
;;; /usr/local/include/ecl/object.h:27:13: note: ‘bool’ is a keyword with ‘-std=c23’ onwardsAn error occurred during initialization:
COMPILE-FILE-ERROR while
compiling #<cl-source-file "filepaths" "src" "filepaths">.
make: *** [Makefile:4: vend] Error 1
robertb@nobara-pc ~/c/vend (portability) [2]>

[fosskers]

I appreciate this contribution, thank you. Unfortunately I had things the way they were for a reason - uiop is a massive dependency and would significantly increase the binary size of vend. As such, I'm unable to accept this PR.

[VisenDev]

I appreciate this contribution, thank you. Unfortunately I had things the way they were for a reason - uiop is a massive dependency and would significantly increase the binary size of vend. As such, I'm unable to accept this PR.

I don't know if I would really describe uiop as a massive dependency.

robertb@nobara-pc ~/c/a/uiop (master)> wc -l **lisp
    69 backward-driver.lisp
   214 common-lisp.lisp
   445 configuration.lisp
   118 contrib/debug.lisp
   933 doc/docstrings.lisp
    22 driver.lisp
   689 filesystem.lisp
   488 image.lisp
   728 launch-program.lisp
   842 lisp-build.lisp
   444 os.lisp
   897 package.lisp
   763 pathname.lisp
   578 run-program.lisp
   743 stream.lisp
   667 utility.lisp
   187 version.lisp
  8827 total
robertb@nobara-pc ~/c/a/uiop (master)>

However, you are correct that the binary size grows to 3M when compiled with ecl.

I will try some things to address this

[fosskers]

I typically avoid monolith packages - which includes things like uiop and alexandria. vend only has 3 dependencies at the moment, and a new one would only be added for a very good reason. As in, to implement some new feature that was impractical to do with just the standard library. Multi-compiler support for vend itself (re: not the compilers it supports with vend repl) is a non-goal of the project.

[VisenDev]

Multi-compiler support for vend itself (re: not the compilers it supports with vend repl) is a non-goal of the project.

Understood, the reason I am working on this is because I had trouble building this with ecl and it seems like a really cool project so I needed some way to build it.

I removed the uiop dependency and instead just created simple wrapper functions around the ecl specific functionality. I also added implementations of these functions that work with sbcl.

[fosskers]

I had trouble building this with ecl

Do you recall what the issues were specifically?

[VisenDev]

I had trouble building this with ecl

Do you recall what the issues were specifically?

I included the error in my initial PR description. Seems to be related to ``typedef int bool` in my distro's GCC.

I rebuilt ecl from source with clang instead, and that worked. However, I am sure I am not the only one who will have problems with getting ecl working - hence, maybe having lower-tier support for at least sbcl might be useful.

[fosskers]

What OS are you on? What version of gcc? I've been able to build vend on Arch with gcc 15, but also on Ubuntu 22.04 with ECL 21 and gcc 11.

[VisenDev]

What OS are you on? What version of gcc? I've been able to build vend on Arch with gcc 15, but also on Ubuntu 22.04 with ECL 21 and gcc 11.

Nobara Linux (it's a fedora based distro). It doesn't have ecl in it's package manager afaik so I had to download and comple ecl manually.

I'm not sure which specific version of GCC. I will be travelling for a few days so I won't be able to check until I return home. Sorry about that. It should be whatever the latest GCC is that's packaged with nobara

[VisenDev]

Specifically, the error seems to be that ecl did not specify the C version. Gcc then assumed the version was C23. bool is a keyword not a normal identifier in C23, so it cannot be typedef'd. See https://gcc.gnu.org/pipermail/gcc-patches/2024-November/670110.html