I don't have a great answer for this situation, either.
If the compilation mode makes sense as a global configuration of an installation, then one possibility would be to add to "etc/config.rktd". Editing that file is less convenient in some ways than command-line arguments, but it's nicer in other ways, since it makes it less likely that mismatches will result from failing to configure every compilation and execution the same way. I can elaborate on the possibility of imitating DrRacket's compilation modes, although I'm not sure it's a good idea for your case. DrRacket sets `use-compiled-file-paths` based on the GUI-selected mode, adding a mode-specific subdirectory before the default subdirectory, and then uses `make-compilation-manager-load/use-compiled-handler` to get the effect of `raco make`. Crucially, though, DrRacket also sets `current-path->mode` to decide, for each module, whether to write to the mode-specific subdirectory or the default subdirectory; otherwise, too many installed modules would be compiled to a mode-specific subdirectory, while DrRacket wants only your files (based on a heuristic for which files are yours) to be compiled in a mode-specific way. So, you could do something like that, and maybe even have your C-code generation depend on the value of `use-compiled-file-paths`. But then you also need to set `use-compiled-file-paths` before running your program; one possible obstacle is that there's not currently a `racket` command-line argument to do that. If you don't care about having results of multiple compilation modes coexist --- which seems likely --- then Matthew Butterick's suggestion to create a variant of `raco make` makes sense to me, although it does seem heavyweight and not composable. Your tool would use `make-compilation-manager-load/use-compiled-handler`, but not need to set `use-compiled-file-paths`. It could accept extra options as a way to avoid environment variables and communicate some other way to the code generator, but I'm not sure what the better way would be. At Mon, 12 Aug 2019 17:34:34 +0300, Dmitry Pavlov wrote: > Hello, > > I posted this question once, nobody answered, this is a second try. > I believe there should be a solution because the problem seems rather common. > > See, I have a DSL compiler implemented in Racket as a #lang, syntax-parse etc. > Like most compilers, it can emit somewhat diifferent code from the same input > program depending on user's needs. > I am looking for a way to specify those needs to the compiler. > > Specifically, I have a backend for C code generation and another backend for > generating Racket syntax objects. I have an option to emit numerical code > with > 64-bit or 80-bit floating point numbers. > > DrRacket has some GUI engine for compiler parameters (debugging, populate > "compiled" directories etc), but I do not know how to use them in raco make, > let alone bring my own options to DrRacket or raco make. > > With C, everyone is happy with macros and built-in options, e. g. > > gcc -O3 -DREAL=double -DDATABASE=POSTGRES prog.c > > > The best idea for Rackey I have so far is to use good old environment > varibles, e. g. > > REAL=double BACKEND=Racket raco make myprog.mylang > > But it has its obvious drawbacks. What do I do instead? > > Best regards, > > Dmitry > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/1E315A92-E90E-45F5-99C6-94AF25F3 > 25B3%40iaaras.ru. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/5d5511d4.1c69fb81.4a779.1158SMTPIN_ADDED_MISSING%40gmr-mx.google.com.
