> From: Paul Smith <psm...@gnu.org> > Cc: make-...@gnu.org, bug-make@gnu.org > Date: Sat, 27 Apr 2013 14:28:18 -0400 > > On Sat, 2013-04-27 at 20:55 +0300, Eli Zaretskii wrote: > > Note: there's one more major feature in current git repo that needs to > > be made available on Windows: dynamic loading of extensions. That is > > my highest priority for Make todo list. > > Yes. I wonder if there are features of gnulib which make this work in a > cross-platform way? I've often wondered if we might get some win out of > utilizing gnulib more in GNU make code.
AFAICS, gnulib does not offer any modules that support dynamic loading of shared libraries. > However, I think that investigation and reworking will need to wait > until after the next release. I don't want to open that can of worms > yet... at least not widely. But if you see something there that would > make your work for "load" simpler let me know and we'll look into it. I added a similar facility to Gawk, but there a problem was much simpler, because Gawk itself was tracking the loaded extensions in platform-independent code. So my emulation of dlopen didn't need to support NULL as its first argument, and didn't care about RTLD_GLOBAL. By contrast, the way Make's code in load.c is written, it relies on dlopen to track the shared libraries already loaded. This is a PITA on Windows, because there's no similar functionality built in, and the emulation of dlopen will have to record each loaded extension in some internal data structure, and search that when dlopen is called with its 1st argument NULL. Not rocket science, granted, but it does make the job larger and the required testing more extensive. If Make could behave like Gawk, I could have simply copied the code I wrote for Gawk and reuse it almost verbatim. > One other thing: I want to make a format cleanup commit at some point to > deal with a number of annoying issues related to TABs, EOL syntax, etc., > as well as update copyright dates, etc. I don't want to do that when it > will conflict with major work anyone else is doing, so let me know when > a good time is for you. As far as I'm concerned, you can do it whenever you want. I'd be greatly surprised if git couldn't figure out how to merge stuff like that cleanly. CVS could have barfed, but not git (or any other modern VCS that tracks the history DAG). _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make