I have a shallow understanding of GNU Make, which is only somewhat less-shallow as a result of recently redesigning my blog to be Makefile-driven.
In the process I learned to like using make variables. I learned that a variable can be populated from make functions like $(wildcard) $(patsubst) and the ultimate escape hatch $(shell). So, if you have (say) 5 unique stanzas, it might be possible to arrange this as 5 variables -- each of which is a list of that kind of source or target files. Then you can state the build recipe once in a single rule for each. If the 5 kinds of things have distinct file extensions, or are in distinct subdirs, this is fairly easy to do with $(wildcard) and/or $(patsubt). Otherwise (if you can't or prefer not to give them distinct extensions or locations), then potentially you can use $(shell) to run something that knows how to distinguish them. Maybe a find or grep command. Maybe even a little .rkt program. So my guess is that the means of abstraction you need, does exist in GNU Make. But even so, it sounds like you might not enjoy using it. On Tue, Apr 16, 2019 at 4:13 PM Hendrik Boom <hend...@topoi.pooq.com> wrote: > > On Tue, Apr 16, 2019 at 09:54:03PM +0200, da...@erl.nu wrote: > > Hendrik, > > > > What is that you are trying to do, maybe you are misunderstanding some > > concept about make? > > > > It seems to me that the whole point of make is to "run a program" whenever > > some of the files have changed. > > Yes, that part of make is easy. > > The problem comes when you have many files that have to be made > depending on many files and there is a repetitive nature to the > dependencies. The kind of similarity that is handled by abstraction in > any normal programming language. > > And make itself has rules that can be used to do things like make *.out > files from *.in files based on the file types, a long as the rules can > be expanded by filling in the rest of the file names. These are used > when it provides, say, default rules to compile .c files to .o files > and the like. > > This is, I guess, a kind of abstraction. But abstraction that takes > only one parameter is a poor kind of abstraction. > > There seems to be no mechanism to provide additional parameters to > these rules, to accomodate slight variations in the stanzas. > > I've thought of using Racket to generate stanzas. Or to avoid > generating Makefiles altogether and directly implement make-like > semantics in Racket using its profound flexibility and then to use > Racket code to Make whatever I want. > > But maybe, just maybe, there are already better tools than GNU make. > > -- hendrik > > > > > > Regards, > > > > David > > > > On 2019-04-16 21:25, Hendrik Boom wrote: > > > I'm sending this here, not because it's directly related to Racket, > > > nor because i think you all are experts in make or GNU make, but > > > because you are reasonable erudite in language appreciation. > > > > > > I, like many others, have been using a Makefile as a recipe to make a > > > lot of files from other files. > > > > > > The trouble is that a lot of the stanzas are quite repetitive. I want > > > to refactor. > > > > > > If I were writing this in any other language then make, i would just > > > define a function with about three or four short parameters and call it > > > many times, each time doing the equivalent of several of these stanzas. > > > > > > Roughly speaking, the abstraction tools of GNU Make are terrible. > > > > > > I'd like to ask you, what other tools might you actually recommend to > > > used in addition to make, or instead of it, that make the build > > > process more like normal programming? > > > > > > If I could get make to run a program to make another makefile and then > > > execute that new makefile, I suppose I could write the program that > > > makes all the repetitive (but not quite the same) stanzas. But that > > > would likely make the build process somewhat obscure. > > > > > > Sure, I could invent something. But chances are, someone else already > > > has invented something better than I'd improvise. > > > > > > -- hendrik > > > > -- > > 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 racket-users+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > -- > 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 racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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 racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
