Programmer <[email protected]> writes: > [email protected] (Timo Myyrä) writes: >> Could you give example just how this would make development easier compared >> to >> using Quicklisp? > It would be convenient to be able to start Common Lisp development > from a fresh install and without fooling around with Quicklisp. I'd > be using a trustworthy, secure, and well-written package manager > instead. > >> The ports development only has those libraries that are needed by some >> applications. It shouldn't be used to duplicate the languages own package >> manager. > It seems a bit odd to port over end-software just because I want the > libraries present, but alright; I can start work on that. > > Solene Rapenne <[email protected]> writes: >> CL developers use quicklisp, not the system CL libs. So, adding more ports >> requiring work and openbsd developers time for 0 benefits, that's a no-go. > I don't use Quicklisp. Just because it's popular doesn't make it a > standard. > >> If a Common LISP program had to be ported and required porting common >> lisp libraries as dependencies to work, then, we would consider having CL >> libraries in the ports tree. >> >> Starting from the end, aka porting libraries, "just in case" we will need it >> in >> the future, would be wasted time. > As above, alright. > >> You can help by updating ecl, sbcl, clisp or stumpwm if you want to hack >> common >> lisp ports. > I can work on that as well. Is there a list of anything that needs to > be done with regards to these anywhere? I would be interested in > getting SBCL and friends to work under OpenBSD on the same platforms > supported under GNU/Linux, so that's something I can start looking > into, certainly.
If you want to have a project idea, then fixing the threads on SBCL would be prime candidate. Timo
