Hello all, A rather long email with a long introduction and some simple make questions later...
On a Debian trixie computer I am (with others) developing a GPL licensed inference engine whose source code in C++ is on https://github.com/RefPerSys/RefPerSys/ See http://refpersys.org/ for more (or ask me to send you a PDF paper describing ideas) (BTW contributors are welcome, and RefPerSys is work in progress in spring 2025; I am inspired by ideas from Jacques Pitrat on http://bootstrappingartificialintelligence.fr/WordPress3 ) https://github.com/RefPerSys/RefPerSys/commit/7a01c497d53c1312571968d7950f30965df8eaf6 is the current commit of RefPerSys (REFlexive PERsistent SYStem) I am referring to. RefPerSys is currently able to load its garbage collected memory heap at startup from textual files inside its persistore/ directory and to dump that heap in a mix of JSON and generated C++ code following ideas from https://arxiv.org/abs/1109.0779 RefPerSys contains light values but also heavy objects uniquely identified by their objid, externally represented by a string like _2c32kYjX53f04obwxm (internally it is a 128 bit unique id). that objid is globally unique (inspired by UUID but with a C++ compatible syntax). The generated/rps-constants.hh & generated/rps-roots.hh C++ files contains such ids. The build system is using GNU make 4.4 extended with GNU guile 3. The first step is a configuration step (to be run once) which is run with make config The configuration program is tools/do-configure-refpersys.c and using GNU readline to ask a few questions. It generates a _config-refpersys.mk which is -include-d in our GNUmakefile, containing definitions like REFPERSYS_CXX=/usr/bin/g++-14 or REFPERSYS_FLTKCONFIG=/usr/local/bin/fltk-config etc RefPerSys accepts dlopen-ed plugins and generate plugins when running. So in some runs, RefPerSys is generating a temporary C++ file, compiling that temporary C++ file to a shared temporary plugin, and dlopen-ing that temporary plugin. There are also hand-written C++ plugins (we hope to get rid of them in the future) like RefPerSys/plugins_dir/rpsplug_create_cplusplus_primitive_type.cc which contains comments in how to use it. RefPerSys C++ plugin files could be generated by RefPerSys itself. (the C++ generation is incomplete in file cppgen_rps.cc) RefPerSys has also a mode where it generate a C++ file to be completed by its user in his $EDITOR (and that completed C++ file is compiled to a dlopen-ed plugin). RefPerSys C++ plugin files (which later will be generated and today are hand- written to follow our coding conventions) may contain descriptive comments telling which Debian packages are needed by them. So they are not compiled to shared objects by running just make but by our utility program do-build-refpersys-plugin That utility program used to invoke ninja-build to compile a RefPerSys C++ plugin to a shared object, but we are switching to GNU make extended by GNU guile. The idea is that some descriptive comments in a generated C++ plugin would contain GUILE code used by GNU make to compile that C++ code to a shared object. C++ code can refer to RefPerSys constant object using rpskob_9uwZtDshW4401x6MsY syntax in C++, and the dumping code in file dump_rps.cc is scanning the C++ code for such identifiers. So I need to write GUILE code for GNU make which invokes recursively make and I don't know how to do so. The extraction of that GUILE code (inside C++ comments in generated C++ code) has to be coded in do-build-refpersys-plugin.cc My question is how to invoke in GNU guile code (generated by do-build-refpersys- plugin.cc) the build of a new GNU make target. So I want an example of GNU guile code (invoked by GNU make) which triggers the build of a given GNU make target identified by a GNU guile string value. Thanks for your help PS: In French https://listes.april.org/wws/arc/technique/2025-02/msg00002.html -- Basile STARYNKEVITCH <bas...@starynkevitch.net> 8 rue de la Faïencerie 92340 Bourg-la-Reine, France http://starynkevitch.net/Basile & https://github.com/bstarynk
