> Date: Mon, 29 Apr 2013 18:19:09 +0100 > From: Tim Murphy <tnmur...@gmail.com> > Cc: "Paul D. Smith" <psm...@gnu.org>, "bug-make@gnu.org" <bug-make@gnu.org> > > > 2. The fact that the dynamic object's file extension (.so) is exposed > > to the Makefile is unfortunate, because it will hurt portability of > > Makefiles: the extension on Windows is .dll. Can we omit the > > extension and append it internally? > > > > "load" allows one to build the plugin from within the makefile so you have > to deal with platform specific problems right there.
How can one deal with them? The underlying OS is not easily detectable by Make. In any case, these problems are bets avoided to begin with, rather than solved when they appear. > > . I suggest to request that the buffers for expansions and > > evaluation by gmk_expand and gmk_eval be provided by the caller. > > It is not safe (and not very convenient) to return buffers > > allocated internally by these functions, because the dynamic > > object might be compiled/linked with an incompatible > > implementation of memory allocation routines. > > > > Yes! > > IMHO the plugin needs to be able to allocate and deallocate memory in > "gmakes world" i.e. you need gmk_alloc() and gmk_free(). That could also work, but sometimes will probably be inconvenient. E.g., you'd need to copy data from a buffer that was already allocated, just not with Make-compatible allocator. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
