Re: dynamic object searching (was: Re: Dynamic objects)

[Paul Smith]

On Mon, 2013-04-29 at 17:00 -0400, David Boyce wrote:
> On Mon, Apr 29, 2013 at 4:34 PM, Paul Smith <address@hidden> wrote:
> > Plus on UNIX any extension is acceptable since we're using dlopen()
> > (even with the normal linker you can give any library name you want,
> > it's only the -l flag that makes assumptions).  Maybe someone wants to
> > write pattern rules to build their GNU make loadable objects with a
> > suffix ".gmkso" to distinguish it (and use a different rule) from
> > building normal .so shared objects.
> >
> > I want to be sure the benefits outweight the loss of flexibility before
> > we go down that path.
> 
> Why not try opening the pathname as given, and if that fails append
> the platform-standard extension and try again?

The issue is that we rebuild loaded objects if they are out of date.
That means we need to do the whole "try to remake" thing.  That gets
more complex if there are multiple possible names for the loaded object.

We can do the search and if we find one then it's easy: we just try to
rebuild it.

But if we don't find one, how do we choose what to build?  We could use
the same algorithm and try to build each one in turn (although that
would be a pretty big change to the code; we don't really have a way to
say "build A or B or C... stop after the first one that succeeds or fail
if none do").  Although starting with an unadorned file like "foo" is
not going to work so well since it will match lots of try-anything
rules.

It's just not pretty.

> > It's probably a good idea to have make predefine a variable containing
> > the "host" architecture, to avoid the need for uname.  We currently have
> > an internal variable "make_host" which is the GNU autoconf --host value
> > on systems where configure runs, and the various config.h templates have
> > hardcoded values.  Maybe we could do something with this (just using the
> > --host value might be too arbitrary, I'd have to look at the options).
> 
> I've twice submitted a patch to provide make_host as a make variable,
> but they've gone into the ether. It's a one-line patch and hugely
> useful IMHO considering the number of people who've had to reinvent
> the $(if $(shell uname)) etc wheel. It's impossible to determine how a
> given user or community will define "platform", so no variable will
> work for everybody, but I think make_host is pretty hard to improve
> upon.

Well, David, when you suggested it I wasn't so sure.  But now that I've
thought of it myself... brilliant!! :-p :-)

I'm not saying make_host is wrong.  I do wish there was something more
generic available (maybe in addition) that let people know "posix" vs
"windows" vs. "vms" vs. "amiga" vs. whatever, and avoid a lot of
makefiles with "if linux or freebsd or openbsd or aix or hpux or ...".

But I guess you get into sticky areas: is MacOS "posix" even though it
has so many differences from stock BSD?  Are "windows" and "msdos" the
same?  What about "msys" vs. "cygwin" etc.?

>From the standpoint of writing a makefile I guess what you really want
to know is, does this environment have a POSIX shell environment, or
Windows command.com, or VMS shell (whatever that is)?  Or something else
(I'm not so familiar with all the variations on the Windows side)