Re: asdf | Can't generate the documentation (#7)
Hi.
Is it enough to begin the Makefile with `all' instead of `website'?
Currently typing `make' leads to the deployment of docs.
<---diff.patch begins--->
diff --git a/uiop/doc/Makefile b/uiop/doc/Makefile
index 265307b8..8b0ae952 100644
--- a/uiop/doc/Makefile
+++ b/uiop/doc/Makefile
@@ -10,11 +10,11 @@ webfiles = ${output}
.PHONY: clean html pdf include clean-include clean-crap info doc
texinfo website
+all: pdf html info clean-crap
+
website: all
rsync -lt --no-g ${webfiles} ${website}
-all: pdf html info clean-crap
-
clean-include:
rm -rf include
<diff.patch ends--->
Regards,
Hugo Ishimaru
2019年5月17日(金) 0:38 Pascal :
>
> When I type make in asdf/uiop/doc, the process fails like this:
>
> […]
>
> rsync -lt --no-g uiop.html uiop.pdf common-lisp.net:/project/asdf/public_html/
>
> The authenticity of host 'common-lisp.net (148.251.248.130)' can't be
> established.
>
> ECDSA key fingerprint is SHA256:ztRL/T8tKsmjW1Ao6pvGcxg4o035wKg2k8rLuG9W3yU.
>
> Are you sure you want to continue connecting (yes/no)? yes
>
> Warning: Permanently added 'common-lisp.net,148.251.248.130' (ECDSA) to the
> list of known hosts.
>
> pas...@common-lisp.net: Permission denied (publickey).
>
> rsync: connection unexpectedly closed (0 bytes received so far) [sender]
>
> rsync error: error in rsync protocol data stream (code 12) at
> /BuildRoot/Library/Caches/com.apple.xbs/Sources/rsync/rsync-52.200.1/rsync/io.c(453)
> [sender=2.6.9]
>
> make: *** [website] Error 12
>
> I've tried with the version of rsync included with Mac OS X 10.14.4 and also
> installed the most recent one from Homebrew, but should it even try to
> connect to the server to generate the documentation?
>
> —
> Reply to this email directly or view it on GitLab.
> You're receiving this email because of your account on
> gitlab.common-lisp.net. If you'd like to receive fewer emails, you can
> unsubscribe from this thread or adjust your notification settings.
Re: how to distinguish public vs private (entry-point vs internal) systems
Hi,
when I read your post, I instantly came up with the system that may
not be the target of OPERATE like
;; foo.asd
;; https://gist.github.com/privet-kitty/84350b73d528533ac8e19e5bba6aa333
(defpackage :foo.asdf
(:use :cl :asdf :uiop)
(:export #:hideable-system))
(in-package :foo.asdf)
(eval-when (:compile-toplevel :load-toplevel :execute)
(defclass hideable-system (system)
((private :initform nil :initarg :private :reader private-p))
(:documentation "If PRIVATE is true, ASDF signals an error when
one tries to OPERATE this system."))
(defmethod operate :around (operation (component hideable-system)
)
(if (private-p component)
(error "Private system ~S cannot be directly operated."
(component-name component))
(call-next-method
(defsystem "foo"
:license "public domain"
:depends-on ("foo/private")
:components ((:file "main")))
(defsystem "foo/private"
:pathname "private"
:class "FOO.ASDF:HIDEABLE-SYSTEM"
:private t
:components ((:file "package")))
Here FOO/PRIVATE cannot be OPERATEd (but can be PERFORMed and then
loaded, compiled, tested etc. via FOO). It seems to work at least
superficially, though ASDF Best Practices states:
> You SHOULD NOT define methods on asdf:operate --- most of the time it's
> totally the wrong thing
> because users would not be "operating" on your system, but on their system
> that depends on it.
> Instead you SHOULD define methods on asdf:perform, asdf:component-depends-on,
> etc.
https://gitlab.common-lisp.net/asdf/asdf/blob/master/doc/best_practices.md
Anyway, I don't have a sufficient knowledge on ASDF's internal.
wild-package-inferred-system
Hi all, I have made an extension of package-inferred-system that interprets star `*' and globstar `**' in a package name, which I will use in the future for my library. https://github.com/privet-kitty/wild-package-inferred-system (My motivation is to eliminate the need for manually creating `foo/.../all'-type subsystems that exist only to use-reexport all .lisp files.) In accordance with the ASDF Best Practices by Faré, I let you know the non-exported facilities of ASDF I had to used: PRIMARY-SYSTEM-P, *DEFPACKAGE-FORMS*, *PACKAGE-INFERRED-SYSTEMS*, AROUND-COMPILE-HOOK, RELATIVE-PATHNAME. I would appreciate any suggestion or correction for the design and implementation of this extension, of course. Regards Hugo Ishimaru
Re: Extracting a UIOP's manual
Hi all, I have added the UIOP's manual to index.html and integrated the generation into the main Makefile just like that of ASDF (rsync is not tested): https://github.com/privet-kitty/asdf/commit/907ab8bea2cb28392fe178107e559af8a1d0e70d I wish this will be helpful to you. (I'll do a merge request if you need, of course) Regards, Hugo Ishimaru 2018-08-15 15:59 GMT+02:00 Hugo Ishimaru : > Hi all, > > I have extracted a UIOP's manual from docstrings: > https://privet-kitty.github.io/etc/uiop.html > It's not perfect in any means as docstring isn't written in a markup > langugage, but will be at least a comprehensive reference. The relevant fork > of ASDF is in Github: > https://github.com/privet-kitty/asdf/tree/uiop-man/uiop/doc > The greater part of the generation conforms to that of Alexandria, which > depends on SBCL (sb-texinfo). > > I send this mail as it states >> Help wanted extracting working documentation from UIOP's docstrings. > in README.md though I might not understand a historical context. > > Regards > Hugo Ishimaru >
Extracting a UIOP's manual
Hi all, I have extracted a UIOP's manual from docstrings: https://privet-kitty.github.io/etc/uiop.html It's not perfect in any means as docstring isn't written in a markup langugage, but will be at least a comprehensive reference. The relevant fork of ASDF is in Github: https://github.com/privet-kitty/asdf/tree/uiop-man/uiop/doc The greater part of the generation conforms to that of Alexandria, which depends on SBCL (sb-texinfo). I send this mail as it states > Help wanted extracting working documentation from UIOP's docstrings. in README.md though I might not understand a historical context. Regards Hugo Ishimaru
