Replies: 1 comment 8 replies
-
This feels to some extent like what we have to do for the kernel: we need there to do non-standard tasks relatively early on, in that case creating format files. That means coding up some of the work yourself in Lua, as the simple 'fill in the blanks' idea runs out of steam, but I don't think it's impossible. (Unpacking with the tree isolated is also something the kernel needs, so again that aspect for |
Beta Was this translation helpful? Give feedback.
8 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I don't know if this is the (or a) right place to ask, so tell me to get lost otherwise. [I have zero experience with GitHub discussions.]
I basically want to ask if
l3build
at all;l3build
with something else (eithermake
or something simpler like a shell script)I have a bunch of font packages (which correspond to those I've put on CTAN, but the latter are all badly out of date). These all depend on
nfssext-cfr
.nfssext-cfr
has a fairly minimalbuild.lua
and an experimental test file. The package doesn't usedtx
/ins
(though it could, if that matters).So I have a directory
nfssext
and then I have a bunch of sub-directories:nfssext-cfr
,electrumadf
etc. (Not a bundle so there's no top-level build script.) I'm currently trying to figure out how to set upelectrumadf
in a way which makes some kind of sense (at least to me). I started with this one because it is simpler than some of the other cases: fewer fonts, a single.sty
and relatively simple configuration.So
electrumadf
basically consists of the standard kinds of files you'd expect from an end-user perspective:enc
,map
,tfm
,vf
,pfb
,fd
,sty
and documentation (pdf
, readme & manifest). It usesfontinst
,finstmsc
,plttf
,vptovf
etc. to generate the font files. In order to create the package, I need todtx
-> someetx
,mtx
+sty
and a couple oftex
etx
,mtx
, possiblyenc
enc
should be generated, but to do that I'd have to isolate the build directory from TL's tree, which I obviously can't do, so I think I just specify these by hand*-drv.tex
, convert*.pl
to*.tfm
and*.vpl
to*.vf
and compile*-map.tex
*.dtx
and a test*.tex
As far as I understand it,
l3build
anddocstrip
can do 1, 2, 4 and 5. But I don't think they can do 3 - at least, not easily.- I don't think I can use
l3build
to compile*-{drv,map}.tex
since they are not docs and the format differs from the documentation (?)- I could just execute things directly from
build.lua
, but I don't know how to ensure things are done in the correct order (?)make
could do all of it (in theory), but not anywhere near as conveniently. Moreover, I cannot set up testing withmake
which would be anywhere near as good asl3build
. (That's not so important forelectrumadf
, but it matters rather more fornfssext-cfr
where visual comparisons would be much harder, even if I had fonts with all the relevant features. Since I don't, it is impossible. Withl3build
I can easily fake them, but I need the logging output and I want it normalised.)On the other hand,
make
can easily handle 3, which I'm not surel3build
can. In particular,make
can easily handle the dependencies and build recipes. (I'm not complainingl3build
can't do this. I don't see any reason it should. Anymore than I'd expectmake
to handle TeX-specific testing.)So should I use both
make
andl3build
?l3build unpack
, then runmake
and then runl3build test
etc.?make
runl3build
and handle all the dependencies, but, as far as I can tell,l3build
always recreates targets even if the sources have not changed, whereasmake
relies on this not happening. (Or perhaps I should say thatdocstrip
always recreates targets rather thanl3build
.)l3build
callmake
, but I'm not sure how to handle the sequencing and doing so may still be liable to problems of illusory newness.Or should I just handle 3 above by hand and/or shell script? (I have scripts to do all kinds of stuff
l3build
now does better, but not, apparently, this.)Or only use
l3build
for tests?Or I could unravel the
dtx
/ins
since I only just barely learnt to do this and the process isn't really endearingdocstrip
to me, but, though that would make things more consistent, I don't think it would actually help.[I have read most of the discussions. I also searched for relevant bugs, either open or closed. And I searched TeX SE. I found one question about
l3build
and packaging fonts, but that didn't involve supporting 8-bit engines or, therefore, generating all the files required to do so. I have tried to read thel3build
documentation but some of it might just as well be written in ancient Aramaic. I just don't know enough to know what it is telling me. I don't even know enough to know what it is I don't know except in a few very limited cases. If I'm really not meant to be trying to do this without learning Lua first, as opposed to trying to figure out bits of it along the way, just say so. In that case, it would help a lot to know which bits of Lua are required.]Beta Was this translation helpful? Give feedback.
All reactions