Greetings! Waldek Hebisch <de...@fricas.org> writes:
> On Fri, Feb 07, 2025 at 08:59:33AM -0500, Camm Maguire wrote: >> Greetings! OK I've pushed a quick commit addressing this issue which >> seems to be working -- please let me know what you think. > > It did not work: 'config' include is in build tree and normally not > present in source tree (it could be in source tree if you previously > build there). > > There were missing dependencies, not a problem for build itself > but could be very confusing if one tries to re-make after change. > > I would also prefer to avoid overlong lines. Diff with my > changes attached. Thank you so much -- looks great to me, and just committed to restore trunk out of source tree builds. > > BTW: I prefer to commit things after enough testing, to have > clean history and to avoid broken builds for people fetching trunk. > Duly noted, and my apologies. >> > I wrote compiler::link many years ago as a stopgap compromise to get a >> > standalone separate GCL to support the standard applications. Prior to >> > this it was conventional to take snapshots of the GCL source code and >> > embed it into the source of the applications, with the obvious >> > maintenance difficulties accompanying. I do not intend to withdraw >> > compiler::link anytime soon, but it alone requires shipping a large >> > number of GCL source files and compiled libraries alongside the GCL >> > binary. The alternate '(load "foo.o")(save-system "bar")' lisp paradigm >> > is clearly dominant, and arguably a distinctive feature of the lisp >> > 'world'. Supporting two different linkers is fragile and an extra >> > maintenance headache I would like to avoid. FRICAS is the last >> > application still using it. > > AFAICS both dumping and 'compiler::link' are useful. 'compiler::link' > seem to be only possibility if one only has binary object files > (say from non-C compiler) or static library. And with all other > Lisp-s FriCAS can link objects created from C files, either staticaly > or dynamically. Currently this include business is managable, but > I have plans for more C files where I may need target-specific > options for good performance (the idea is to link-in multiple > variants and choose good one at runtime). Thanks for the feedback. I am wondering what you think of the persistent linking of new C code as described below: https://lists.nongnu.org/archive/html/gcl-devel/2007-06/msg00001.html One can take any C-interface shared object and permanently link it into a GCL image in this way -- the only difference with compiler::link is that the object remains in a separate file. Many years ago I worked on a scheme for switchable access to optimized blas/lapack routines (ATLAS) based on the simd extensions in the running cpu via configuration/instructions to ld.so. I'm sure things have evolved since then and there is some canonically preferred method, but it is and was an eminently workable idea. Take care, -- Camm Maguire c...@maguirefamily.org ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/878qqgd2g7.fsf%40maguirefamily.org.
