Thanks for the clarifications: And well: it's arguably a very common use pattern in make.
And maybe I should have been more precise: really they are called pattern rules in make (or at least: that's what I want) - and as I can read on: https://www.gnu.org/software/make/manual/html_node/Suffix-Rules.html "Suffix rules are the old-fashioned way of defining implicit rules for make. Suffix rules are obsolete because pattern rules are more general and clearer. They are supported in GNU make for compatibility with old makefiles.[...]" (thus: with make pattern rules - for my use case:) %.pdf: %.fo cfg fop -c cfg -fo $< -pdf $@ shake (mentioned already), redo has default targets (file default.pdf.do): redo-ifchange $2.fo cfg fop -c cfg -fo $2.fo -pdf $3 etc. - so for me this is a blocker for now (I use them a lot) - I was just giving zuo a try, which otherwise looks promising. Thanks again, Andreas Matthew Flatt <[email protected]> writes: > At Tue, 25 Oct 2022 05:38:15 +0100, Andreas Reuleaux wrote: >> I want a make/shake >> style suffix rule, how to create (in general) a .pdf from a .fo >> >> And things start to get complicated - there should an easy >> solution to this, I guess. > > There's no particular support for that right now. > > > In cases where I need a rule to map over files with the same suffix, > I've used `map` to generate a rule for each file. So, normally, I'd > have a list of ".pdf" files, and then I'd map a rule template over that > list to generate a list of rules: > > ... > ,@(map > (lambda (.pdf) > (define .fo (path-replace-extension .pdf ".fo")) > `[:target ,.pdf (,.fo) > ,(lambda (dest token) > (shell/wait "fop -c cfg -fo" .fo "-pdf" dest))]) > pdf-files) > .... > > Using `map` is not the same as having a suffix rule, because it > requires the list `pdf-files` to be written down. Arguably, explicitly > defining a list like `pdf-files` is a good practice for the makefiles > that Zuo was designed to replace. > > > But there are cases where a suffix rule would be a good choice, and so > I'm not opposed to adding support. I'm tempted to work on this, but I > should do some other things right now, so here are a few thoughts in > case someone else is interested to try. > > The `target` and `build` layer is flexible enough to support this > addition, but things like `build/command-line` and `find-target` are > not. I imagine that functions like `find-target` that expect with a > list of `target`s would need to handle something more general --- maybe > a `(list/c (or/c target? target-generator?))`. Most of the work is > probably in `make-targets` to set up target generation. > > > Matthew -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/beaa2ef6-afd2-4686-829a-390eb69f5620n%40googlegroups.com. Beyond the Racket Users Google Group, Racket Discussions take place on Discourse ( https://racket.discourse.group/ ) and Discord ( https://discord.gg/6Zq8sH5 ). Discussion (but less active) also takes place on the Racket Slack https://racket.slack.com/ ( sign up at https://racket-slack.herokuapp.com/ ), and IRC #racket https://kiwiirc.com/nextclient/irc.libera.chat/#racket --- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/87sfjcb1h2.fsf%40laptop.
