Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch)
Let me add my voice as a user. If you are one of the lucky people whose builds consist mostly of 1 line of output per rule then you will rarely have any trouble in a good build but try interpreting error messages from compiler/tool X when they're 10 lines from the file that they refer to and don't include the filename in the error message. Try working it out when it's not your code that's being built. This suggests an optimisation where you buffer 5 lines in memory and open a file if there's more but I wouldn't be surprised if the gain is quite small as I suspect that the average build step does so much IO as to make a buffered temp file for the output seem a relatively tiny overhead. I have certainly spent a lot of time wondering why xyz.cpp doesn't have a line 370. I faced this 5 years ago and we had to come up with our own solution rather than wait to convince GNU mission control that we had a problem - which was the only choice given the great difficulty at that job of trying to get permission to make open source contributions. It has already been a very long time coming. You've got it now, thank goodness, in whatever shape or form. Please turn it on. As for reasons: a) I would be surprised if there weren't other changes in the next release that give some people pause for thought before upgrading - why worry about 1 more? e.g. globbing differences between various recent releases caused more pain to me than this is likely to. b) Demand is usually only going to come from the few anyhow. I think this is one of those features that few people will know to turn on but many will benefit anyhow. The reason is that you will start to be able to write generic make output analysis tools. I don't know if you guys have seen Electric Insight, for example. I don't intend this as a plug but I can't help it - it's just the only non-inhouse example that I can think of but I have seen a number of others at various companies. This is a trivial example where you can see that parsing is taking most of the time in this parallel build: https://docs.google.com/file/d/0BwJNUxZZ7qItQlRrUjBmM0tTTDg/edit?usp=sharing It lets you see the state of your parallel build - gives you an intuitive idea of where the time is going and what the errors are and so on. You can't implement tools like this across a general a lot of builds unless they have contiguous recipe output and the surest way to get that is for it to be on by default. You also need recipe separators and timing data but I think you'll realise that eventually now that this step is taken. c) Lets benchmark it on something like an android build and you can make a decision after that? Heck, lets try it with various things and be happy it works. Regards, Tim On 29 April 2013 03:53, Eli Zaretskii wrote: > > From: Paul Smith > > Cc: bug-make@gnu.org > > Date: Sun, 28 Apr 2013 22:03:39 -0400 > > > > Now that we seem to have a workable solution for output synchronization > > for both POSIX and Windows systems, I wonder if we shouldn't consider > > enabling it as the default mode when parallel builds are running. > > I don't think we should do this unless users demand it, which means we > should wait for the next release and some time beyond before making > the decision. > > FWIW, I'm running 8-way parallel Make jobs for many months now, and > never had any trouble interpreting their output, neither when they > succeed, nor when they don't. > > The synchronized output operation annoys me slightly in that there are > distinct time intervals when Make says nothing at all, and then the > output appears in large chunks that get dumped en-masse to the > screen. IOW, the user experience is different and takes time to get > used to. > > ___ > Bug-make mailing list > Bug-make@gnu.org > https://lists.gnu.org/mailman/listinfo/bug-make > -- You could help some brave and decent people to have access to uncensored news by making a donation at: http://www.thezimbabwean.co.uk/friends/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Default output-sync setting
On 04/29/2013 04:53 AM, Eli Zaretskii wrote: >> From: Paul Smith >> Cc: bug-make@gnu.org >> Date: Sun, 28 Apr 2013 22:03:39 -0400 >> >> Now that we seem to have a workable solution for output synchronization >> for both POSIX and Windows systems, I wonder if we shouldn't consider >> enabling it as the default mode when parallel builds are running. > > I don't think we should do this unless users demand it, which means we > should wait for the next release and some time beyond before making > the decision. > > FWIW, I'm running 8-way parallel Make jobs for many months now, and > never had any trouble interpreting their output, neither when they > succeed, nor when they don't. > > The synchronized output operation annoys me slightly in that there are > distinct time intervals when Make says nothing at all, and then the > output appears in large chunks that get dumped en-masse to the > screen. IOW, the user experience is different and takes time to get > used to. > FWIW, I agree with Eli. I think the new behaviour should not be made the default one. Regards, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch)
> Date: Mon, 29 Apr 2013 09:58:50 +0100 > From: Tim Murphy > Cc: "bug-make@gnu.org" > > try interpreting error messages from compiler/tool X when they're 10 > lines from the file that they refer to and don't include the > filename in the error message. That's unrelated: interpreting such output will be hard no matter what order it comes in. > b) Demand is usually only going to come from the few anyhow. I think this > is one of those features that few people will know to turn on but many will > benefit anyhow. The reason is that you will start to be able to write > generic make output analysis tools. People who write programs that parse Make output will find and use this switch anyway; we could announce that prominently in NEWS if you think the feature could go unnoticed. But that is irrelevant to interactive human users and their use cases. > c) Lets benchmark it on something like an android build and you can make a > decision after that? Heck, lets try it with various things and be happy it > works. I already tried it, and I'm not happy, FWIW. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch)
On 29 April 2013 16:19, Eli Zaretskii wrote: > > Date: Mon, 29 Apr 2013 09:58:50 +0100 > > From: Tim Murphy > > Cc: "bug-make@gnu.org" > > > > try interpreting error messages from compiler/tool X when they're 10 > > lines from the file that they refer to and don't include the > > filename in the error message. > > That's unrelated: interpreting such output will be hard no matter what > order it comes in. > cc fred.c -c -o fred.o cc bob.c -c -o bob.o error on line 20 -X Which one? It gets worse when you scale up. Regards, Tim http://www.thezimbabwean.co.uk/friends/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: .ONESEHLL not working as expected in 3.82
> From: Paul Smith
> Cc: bug-make@gnu.org
> Date: Sun, 28 Apr 2013 15:15:09 -0400
>
> I think it pseudo-code it would look something like this:
>
> if (posix-shell)
> {
> ...strip out @-+ from LINE...
> }
> #ifdef WINDOWS32
> if (need a batch file)
> {
> ...write LINE to the batch file & setup new_argv for batch...
> }
> else
> #endif
> {
> ...chop LINE up into new_argv...
> }
> return new_argv;
I fixed it a bit differently, please see commit 9a7fe22.
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
Re: .ONESEHLL not working as expected in 3.82
> From: Paul Smith > Cc: bug-make@gnu.org > Date: Sun, 28 Apr 2013 14:37:29 -0400 > > > My plan was to write dlopen and dlsym, and add them to > > w32/compat/posixfcn.c. But I need to understand the semantics of > > global_dl in order to do that correctly. > > It's up to you how you think it best to implement, whether it makes more > sense to try to reimplement POSIX functions, or do it at a higher level. > Whatever is simpler. OK, done as commit 19a69ba. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)
> From: Paul Smith
> Cc: bug-make@gnu.org
> Date: Sat, 27 Apr 2013 16:58:54 -0400
>
> On Sat, 2013-04-27 at 23:00 +0300, Eli Zaretskii wrote:
> > That would be nice, indeed.
>
> OK, pushed. You should be able to simply write a new load_objects()
> function and drop it in. Or put it into a w32 file or whatever.
Thanks, I did that.
As result of reading the docs and the code, I have a few comments on
this feature, hopefully it will be useful:
1. Doesn't the FSF frown upon capability to load _any_ dynamic
objects? I think they like the GCC method whereby each extension
is required to define a symbol with a certain name
(plugin_is_GPL_compatible in GCC), which is tested at load time,
before the dynamic object is allowed to be loaded.
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?
3. I suggest to extend the search for dynamic object to a
Make-specific directory (${prefix}/share/make/), before falling
back to the "system-specific path". Or maybe even not fall back to
any system-specific defaults, because those are generally set for
shared libraries, not for plugins. (You do NOT want to know where
Windows will look for shared libraries.)
4. It would be good to have at least a single simple example of a
dynamic extension, either in the tarball or in the manual. The
only ones I found are in the test suite; did I miss something?
5. Is the following a valid 'load' directive?
load /foo/bar/
If it is valid, what is its semantics? If it is invalid, the code
in load_object should detect it and give a diagnostics; currently
it will happily use this, and will try to call a symbol _gmk_setup.
6. The diagnostics in read.c:
if (! load_file (&ebuf->floc, &name, noerror) && ! noerror)
fatal (&ebuf->floc, _("%s: failed to load"), name);
is IMO misleading: it says "failed to load" also in the case that
the dynamic object was successfully loaded, but the function called
from it returned zero. It would be better to make a more precise
message in that case.
6. API:
. 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.
. The manual says that the setup function should return non-zero on
success, but the code actually requires a non-negative value;
anything else prevents the dynamic object from being recorded in
.LOADED.
HTH
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)
Sorry to keep adding in my 2c but I have also submitted a plugin
implementation so I have a couple of ideas
On 29 April 2013 17:33, Eli Zaretskii wrote:
>
> 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.
> 4. It would be good to have at least a single simple example of a
>dynamic extension, either in the tarball or in the manual. The
>only ones I found are in the test suite; did I miss something?
>
This is a great idea.
> 6. API:
>
>. 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().
Here's one of the tests:
static char * func_test (const char *funcname, int argc, char **argv)
{
if (strcmp (funcname, "test-expand") == 0)
return test_expand (argv[0]);
if (strcmp (funcname, "test-eval") == 0)
return test_eval (argv[0]);
return strdup ("unknown");
}
That strdup at the end should be a gmk_strdup() if possible.
:-) Probably seems like over-engineering.
Regards, Tim
> ___
> Bug-make mailing list
> Bug-make@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-make
>
--
You could help some brave and decent people to have access to uncensored
news by making a donation at:
http://www.thezimbabwean.co.uk/friends/
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch)
> Date: Mon, 29 Apr 2013 16:40:03 +0100 > From: Tim Murphy > Cc: "bug-make@gnu.org" > > cc fred.c -c -o fred.o > cc bob.c -c -o bob.o > error on line 20 -X > > Which one? Make will actually tell you which one, something like: makefile:342: recipe for target 'oo/i386/acl-errno-valid.o' failed make: *** [oo/i386/acl-errno-valid.o] Error 1 (Copied from a failed "make -j8" run I just did for Emacs.) ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch)
cc fred.c -c -o fred.o cc bob.c -c -o bob.o error on line 20 -X error on line 30 - error on line 330 - makefile:342: recipe for target 'fred.o' failed makefile:350: recipe for target 'bob.o' failed ? Regards, Tim On 29 April 2013 18:25, Eli Zaretskii wrote: > > Date: Mon, 29 Apr 2013 16:40:03 +0100 > > From: Tim Murphy > > Cc: "bug-make@gnu.org" > > > > cc fred.c -c -o fred.o > > cc bob.c -c -o bob.o > > error on line 20 -X > > > > Which one? > > Make will actually tell you which one, something like: > > makefile:342: recipe for target 'oo/i386/acl-errno-valid.o' failed > make: *** [oo/i386/acl-errno-valid.o] Error 1 > > (Copied from a failed "make -j8" run I just did for Emacs.) > -- You could help some brave and decent people to have access to uncensored news by making a donation at: http://www.thezimbabwean.co.uk/friends/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)
On Mon, 2013-04-29 at 19:33 +0300, Eli Zaretskii wrote:
> > From: Paul Smith
> > Cc: bug-make@gnu.org
> > Date: Sat, 27 Apr 2013 16:58:54 -0400
> >
> > On Sat, 2013-04-27 at 23:00 +0300, Eli Zaretskii wrote:
> > > That would be nice, indeed.
> >
> > OK, pushed. You should be able to simply write a new load_objects()
> > function and drop it in. Or put it into a w32 file or whatever.
> 1. Doesn't the FSF frown upon capability to load _any_ dynamic
>objects? I think they like the GCC method whereby each extension
>is required to define a symbol with a certain name
>(plugin_is_GPL_compatible in GCC), which is tested at load time,
>before the dynamic object is allowed to be loaded.
Hm. I guess the concern is that someone will introduce a proprietary
"plug-in"? My position on this is that it would be a violation of the
GPL. I don't believe there is any useful way to utilize this feature
without becoming a derived work of GNU make, since the only way to do
anything with this feature is to invoke GNU make functions. As GNU make
is GPL'd there's no dynamic linking exception. I'll check with the
legal folks.
> 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?
Yes, that should be possible. My concern is that, at least on UNIX, the
rules for this are complex and I don't want to reimplement the runtime
linker :-). Maybe something like, first try the path as given and if
that fails, try adding arch-specific extensions?
The other problem here is that we want to allow rebuilding of dynamic
objects then re-exec'ing make... if we're trying different extensions
THAT can be a real problem... what order do we do this in?
I'm not sure I can come up with a reliable algorithm for this that's
understandable.
> 3. I suggest to extend the search for dynamic object to a
>Make-specific directory (${prefix}/share/make/), before falling
>back to the "system-specific path". Or maybe even not fall back to
>any system-specific defaults, because those are generally set for
>shared libraries, not for plugins. (You do NOT want to know where
>Windows will look for shared libraries.)
I'm not sure about having a make-specific directory. It's not so easy
to do in UNIX--we'd have to modify the LD_LIBRARY_PATH env. var. I
suppose. Also we don't really have a precedent of a "make-specific"
directory like that.
On UNIX there's no way to avoid looking in the system-specific locations
except by forcing the object path to contain a "/". I suppose that if
the object didn't contain a "/" we could prefix it with "./" to force
the avoiding of system paths. On the other hand we DO have precedence
for searching system paths; for example make's "include" will search for
included makefiles in places like /usr/include, /usr/local/include, etc.
even though I can't see how THAT makes sense.
> 4. It would be good to have at least a single simple example of a
>dynamic extension, either in the tarball or in the manual. The
>only ones I found are in the test suite; did I miss something?
No. The documentation does need to be enhanced.
> 5. Is the following a valid 'load' directive?
>
> load /foo/bar/
>
>If it is valid, what is its semantics? If it is invalid, the code
>in load_object should detect it and give a diagnostics; currently
>it will happily use this, and will try to call a symbol _gmk_setup.
Hm. That's odd. It shouldn't try to call an init function unless the
load of the dynamic object succeeds, and I would think that trying to
dlopen("/foo/bar/") would fail. I'll check it out.
> 6. The diagnostics in read.c:
>
> if (! load_file (&ebuf->floc, &name, noerror) && ! noerror)
> fatal (&ebuf->floc, _("%s: failed to load"), name);
>
>is IMO misleading: it says "failed to load" also in the case that
>the dynamic object was successfully loaded, but the function called
>from it returned zero. It would be better to make a more precise
>message in that case.
Yes, good point.
> 6. API:
>
>. 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.
I don't see how this can work easily. We have no idea how large the
buffer will be until after we complete the expansion/eval. The only way
this could work is to use the snprintf() model where we do the expansion
as now, and if it's too small we return the expected length and they'd
have to re-invoke with a larger buffer. However, the thing they've
expanded o
Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch)
On Mon, Apr 29, 2013 at 10:30 AM, Tim Murphy wrote: > cc fred.c -c -o fred.o > cc bob.c -c -o bob.o > error on line 20 -X > error on line 30 - > error on line 330 - > makefile:342: recipe for target 'fred.o' failed > makefile:350: recipe for target 'bob.o' failed > > ? "Doctor, my hammer has a head so large that I always hit my thumb" "Throw out that hammer and get a non-broken one" The GNU tool working around the brokenness of some non-free software? Some would call that collaboration in retaining your chains. :-/ I haven't had a chance to play with the new functionality in the repository, so I'll merely caution that having major new functionality that will affect the user experience be on by default runs the risk of there being a problem and having the new version be tarred-and-feathered, and the projects that would most benefit from the new functionality instead turning it off. If there are other fixes and/or features in this release that people are waiting for, burning them on this would be unfriendly. Philip Guenther ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)
I must clarify - I think that make should provide plugins with an
allocation mechanism. Not the other way around.
the snprintf model for dealing with expansion is not so bad - I mean the
problem is that nobody knows how big an expansion is going to be in the
end, right? So how does make deal with this already? The same way would be
fine for the plugin and it would be nice to not simply push that problem on
to all plugin writers.
Cheers,
Tim
On 29 April 2013 18:59, Paul Smith wrote:
> On Mon, 2013-04-29 at 19:33 +0300, Eli Zaretskii wrote:
> > > From: Paul Smith
> > > Cc: bug-make@gnu.org
> > > Date: Sat, 27 Apr 2013 16:58:54 -0400
> > >
> > > On Sat, 2013-04-27 at 23:00 +0300, Eli Zaretskii wrote:
> > > > That would be nice, indeed.
> > >
> > > OK, pushed. You should be able to simply write a new load_objects()
> > > function and drop it in. Or put it into a w32 file or whatever.
>
> > 1. Doesn't the FSF frown upon capability to load _any_ dynamic
> >objects? I think they like the GCC method whereby each extension
> >is required to define a symbol with a certain name
> >(plugin_is_GPL_compatible in GCC), which is tested at load time,
> >before the dynamic object is allowed to be loaded.
>
> Hm. I guess the concern is that someone will introduce a proprietary
> "plug-in"? My position on this is that it would be a violation of the
> GPL. I don't believe there is any useful way to utilize this feature
> without becoming a derived work of GNU make, since the only way to do
> anything with this feature is to invoke GNU make functions. As GNU make
> is GPL'd there's no dynamic linking exception. I'll check with the
> legal folks.
>
> > 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?
>
> Yes, that should be possible. My concern is that, at least on UNIX, the
> rules for this are complex and I don't want to reimplement the runtime
> linker :-). Maybe something like, first try the path as given and if
> that fails, try adding arch-specific extensions?
>
> The other problem here is that we want to allow rebuilding of dynamic
> objects then re-exec'ing make... if we're trying different extensions
> THAT can be a real problem... what order do we do this in?
>
> I'm not sure I can come up with a reliable algorithm for this that's
> understandable.
>
> > 3. I suggest to extend the search for dynamic object to a
> >Make-specific directory (${prefix}/share/make/), before falling
> >back to the "system-specific path". Or maybe even not fall back to
> >any system-specific defaults, because those are generally set for
> >shared libraries, not for plugins. (You do NOT want to know where
> >Windows will look for shared libraries.)
>
> I'm not sure about having a make-specific directory. It's not so easy
> to do in UNIX--we'd have to modify the LD_LIBRARY_PATH env. var. I
> suppose. Also we don't really have a precedent of a "make-specific"
> directory like that.
>
> On UNIX there's no way to avoid looking in the system-specific locations
> except by forcing the object path to contain a "/". I suppose that if
> the object didn't contain a "/" we could prefix it with "./" to force
> the avoiding of system paths. On the other hand we DO have precedence
> for searching system paths; for example make's "include" will search for
> included makefiles in places like /usr/include, /usr/local/include, etc.
> even though I can't see how THAT makes sense.
>
> > 4. It would be good to have at least a single simple example of a
> >dynamic extension, either in the tarball or in the manual. The
> >only ones I found are in the test suite; did I miss something?
>
> No. The documentation does need to be enhanced.
>
> > 5. Is the following a valid 'load' directive?
> >
> > load /foo/bar/
> >
> >If it is valid, what is its semantics? If it is invalid, the code
> >in load_object should detect it and give a diagnostics; currently
> >it will happily use this, and will try to call a symbol _gmk_setup.
>
> Hm. That's odd. It shouldn't try to call an init function unless the
> load of the dynamic object succeeds, and I would think that trying to
> dlopen("/foo/bar/") would fail. I'll check it out.
>
> > 6. The diagnostics in read.c:
> >
> > if (! load_file (&ebuf->floc, &name, noerror) && ! noerror)
> > fatal (&ebuf->floc, _("%s: failed to load"), name);
> >
> >is IMO misleading: it says "failed to load" also in the case that
> >the dynamic object was successfully loaded, but the function called
> >from it returned zero. It would be better to make a more precise
> >message in that case.
>
> Yes, good point.
>
> > 6. API:
> >
> >. I suggest to request that the buffers for expansions and
> > evaluation
Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch)
Come now - the broken excuse is an excuse. There's plenty of crap free software out there and some poor bastard trying to build it who can't change the source because the people who own it think it should be make's problem. :-) Cheers, Tim On 29 April 2013 19:00, Philip Guenther wrote: > On Mon, Apr 29, 2013 at 10:30 AM, Tim Murphy wrote: > > cc fred.c -c -o fred.o > > cc bob.c -c -o bob.o > > error on line 20 -X > > error on line 30 - > > error on line 330 - > > makefile:342: recipe for target 'fred.o' failed > > makefile:350: recipe for target 'bob.o' failed > > > > ? > > "Doctor, my hammer has a head so large that I always hit my thumb" > "Throw out that hammer and get a non-broken one" > > The GNU tool working around the brokenness of some non-free software? > Some would call that collaboration in retaining your chains. > > :-/ > > > > I haven't had a chance to play with the new functionality in the > repository, so I'll merely caution that having major new functionality > that will affect the user experience be on by default runs the risk of > there being a problem and having the new version be > tarred-and-feathered, and the projects that would most benefit from > the new functionality instead turning it off. If there are other > fixes and/or features in this release that people are waiting for, > burning them on this would be unfriendly. > > > Philip Guenther > -- You could help some brave and decent people to have access to uncensored news by making a donation at: http://www.thezimbabwean.co.uk/friends/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)
> Date: Mon, 29 Apr 2013 18:19:09 +0100 > From: Tim Murphy > Cc: "Paul D. Smith" , "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
Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch)
> Date: Mon, 29 Apr 2013 18:30:37 +0100 > From: Tim Murphy > Cc: "bug-make@gnu.org" > > cc fred.c -c -o fred.o > cc bob.c -c -o bob.o > error on line 20 -X > error on line 30 - > error on line 330 - > makefile:342: recipe for target 'fred.o' failed > makefile:350: recipe for target 'bob.o' failed > > ? You need to look in both anyway. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch)
> Date: Mon, 29 Apr 2013 19:33:10 +0100 > From: Tim Murphy > Cc: Eli Zaretskii , "bug-make@gnu.org" > > Come now - the broken excuse is an excuse. There's plenty of crap free > software out there and some poor bastard trying to build it who can't > change the source because the people who own it think it should be make's > problem. Look, no one is claiming that this feature is useless. I just spent two days researching and implementing it on Windows, something I wouldn't do if I thought it wasn't important to have. What we are talking here is whether to have this turned on by default. I hope you are not going to claim that adding -O to a Make command line to get the new behavior is too hard. By contrast, having to type -Onone to have the _old_ behavior back might very well annoy a few. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch)
One doesn't have to suffer the problems and learn the option exists afterwards. In the end I can understand why a new feature might not be default to start with - until a lot of people have used it and are sure that it works everywhere. Cheers, Tim On 29 April 2013 20:21, Eli Zaretskii wrote: > > Date: Mon, 29 Apr 2013 19:33:10 +0100 > > From: Tim Murphy > > Cc: Eli Zaretskii , "bug-make@gnu.org" > > > > Come now - the broken excuse is an excuse. There's plenty of crap free > > software out there and some poor bastard trying to build it who can't > > change the source because the people who own it think it should be make's > > problem. > > Look, no one is claiming that this feature is useless. I just spent > two days researching and implementing it on Windows, something I > wouldn't do if I thought it wasn't important to have. > > What we are talking here is whether to have this turned on by default. > I hope you are not going to claim that adding -O to a Make command > line to get the new behavior is too hard. By contrast, having to type > -Onone to have the _old_ behavior back might very well annoy a few. > -- You could help some brave and decent people to have access to uncensored news by making a donation at: http://www.thezimbabwean.co.uk/friends/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)
> From: Paul Smith
> Cc: bug-make@gnu.org
> Date: Mon, 29 Apr 2013 13:59:16 -0400
>
> > 1. Doesn't the FSF frown upon capability to load _any_ dynamic
> >objects? I think they like the GCC method whereby each extension
> >is required to define a symbol with a certain name
> >(plugin_is_GPL_compatible in GCC), which is tested at load time,
> >before the dynamic object is allowed to be loaded.
>
> Hm. I guess the concern is that someone will introduce a proprietary
> "plug-in"?
Yes.
> > 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?
>
> Yes, that should be possible. My concern is that, at least on UNIX, the
> rules for this are complex and I don't want to reimplement the runtime
> linker :-). Maybe something like, first try the path as given and if
> that fails, try adding arch-specific extensions?
No, much simpler: _always_ append _a_single_ arch-specific extension,
and try loading that. We should document that extension; using the
one that is used by default by the compiler for producing shared
libraries should be good enough, I think.
> The other problem here is that we want to allow rebuilding of dynamic
> objects then re-exec'ing make... if we're trying different extensions
> THAT can be a real problem... what order do we do this in?
Again, let's use only one extension. .so on Unix, .dll on Windows.
Same as the linker does when you say -lFOO.
> > 3. I suggest to extend the search for dynamic object to a
> >Make-specific directory (${prefix}/share/make/), before falling
> >back to the "system-specific path". Or maybe even not fall back to
> >any system-specific defaults, because those are generally set for
> >shared libraries, not for plugins. (You do NOT want to know where
> >Windows will look for shared libraries.)
>
> I'm not sure about having a make-specific directory. It's not so easy
> to do in UNIX--we'd have to modify the LD_LIBRARY_PATH env. var. I
> suppose.
??? I thought dlopen will gladly use an absolute file name, without
looking at LD_LIBRARY_PATH. Was I wrong?
> Also we don't really have a precedent of a "make-specific" directory
> like that.
Gawk puts them into ${prefix}/lib/gawk.
> >. 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.
>
> I don't see how this can work easily. We have no idea how large the
> buffer will be until after we complete the expansion/eval. The only way
> this could work is to use the snprintf() model where we do the expansion
> as now, and if it's too small we return the expected length and they'd
> have to re-invoke with a larger buffer.
Yes, that's what I had in mind.
> I think we should go with this for now. Hopefully users that do have a
> problem will find a way to make this work.
At least on Windows, it can be a real problem, because the libraries
with which a shared object was linked are hardcoded into it, and
there's more than one way of allocating memory.
How about a callback for allocating memory? Then Make could call that
callback and get memory that the extension could free.
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)
On 29 April 2013 20:12, Eli Zaretskii wrote: > > Date: Mon, 29 Apr 2013 18:19:09 +0100 > > From: Tim Murphy > > Cc: "Paul D. Smith" , "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. > the same way one creates 1 makefile that can build the same code for 2 operating systems - something done every day. You make it up. You run uname with $(shell) or you pass in an argument from a top level script that does know the platform or whatever. In the end you have a bit of makefile that says: foo.dll: foo.obj . load foo.dll or foo.so: foo.o load foo.so SYSTEM:=$(shell uname -s) perhaps one has to say ifeq ($(SYSTEM),) # assume windows foo.dll: foo.obj . load foo.dll else foo.so: foo.o load foo.so endif Regards, Tim -- You could help some brave and decent people to have access to uncensored news by making a donation at: http://www.thezimbabwean.co.uk/friends/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)
> Date: Mon, 29 Apr 2013 20:40:46 +0100 > From: Tim Murphy > Cc: "Paul D. Smith" , "bug-make@gnu.org" > > > How can one deal with them? The underlying OS is not easily > > detectable by Make. > > > > the same way one creates 1 makefile that can build the same code for 2 > operating systems - something done every day. You make it up. You run > uname with $(shell) or you pass in an argument from a top level script that > does know the platform or whatever. In the end you have a bit of makefile > that says: > > foo.dll: foo.obj >. > load foo.dll > > or > > foo.so: foo.o > > load foo.so First, there's no uname on Windows. You are in fact saying that in order to run a Makefile one would need something similar to autoconf. More importantly: this is a lot of trouble we are going to impose on _users_, just to decide which one of the two extensions to use, something that Make can know a-priori to begin with. How does that make sense? When users will ask why didn't we teach Make to do that automatically, what answer will we have for them? ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
memory allocation (was: Re: Dynamic objects)
On Mon, 2013-04-29 at 19:30 +0100, Tim Murphy wrote: > I must clarify - I think that make should provide plugins with an > allocation mechanism. Not the other way around. It's probably a good idea for make to provide a "gmk_free()" function that will free memory returned to the plugin when it calls gmk_*() functions such as gmk_expand(). Is that sufficient to deal with this problem? > the snprintf model for dealing with expansion is not so bad - I mean > the problem is that nobody knows how big an expansion is going to be > in the end, right? So how does make deal with this already? The same > way would be fine for the plugin and it would be nice to not simply > push that problem on to all plugin writers. make calls malloc() and if the buffer is not big enough it calls realloc(). But the problem is that while make is expanding and allocating, it's also interpreting. And that interpretation might have side-effects. Suppose, for example, we enhanced gmk_expand() to take a buffer and a plugin invoked: gmk_expand(buf, buflen, "$(info expanding) $(FOO)"); This will return the expansion of the FOO variable, but it will ALSO print "expanding" as the result of calling the info function. Now suppose that the result of expanding $(FOO) was too large to fit into buf, so the function returns the length needed and the plugin reallocates the buffer to be large enough and re-invokes gmk_expand()... now it will print "expanding" AGAIN. Of course the side-effect might not be so innocuous as double-printing. On Mon, 2013-04-29 at 22:34 +0300, Eli Zaretskii wrote: > At least on Windows, it can be a real problem, because the libraries > with which a shared object was linked are hardcoded into it, and > there's more than one way of allocating memory. > > How about a callback for allocating memory? Then Make could call that > callback and get memory that the extension could free. This could work, at the cost of an extra allocation and buffer copy for each invocation of gmk_expand() (etc.) We would basically call our normal expand and get back a buffer allocated by us, then if there was a separate allocator registered we'd call that to get enough memory to hold the buffer, then copy over from our buffer to theirs, then free our buffer and pass back theirs. If the method at the beginning of this email (providing a gmk_free() function that will free memory returned from gmk_expand()) is sufficient, though, wouldn't that be a better/more efficient solution? As long as we don't have one side (between make and the object) allocating memory and the other side freeing it, is that enough? ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)
> Date: Mon, 29 Apr 2013 22:34:51 +0300
> From: Eli Zaretskii
> Cc: bug-make@gnu.org
>
> > Also we don't really have a precedent of a "make-specific" directory
> > like that.
>
> Gawk puts them into ${prefix}/lib/gawk.
Correction: ${prefix}/lib/gawk-extensions.
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
dynamic object searching (was: Re: Dynamic objects)
On Mon, 2013-04-29 at 22:34 +0300, Eli Zaretskii wrote: > > Yes, that should be possible. My concern is that, at least on UNIX, the > > rules for this are complex and I don't want to reimplement the runtime > > linker :-). Maybe something like, first try the path as given and if > > that fails, try adding arch-specific extensions? > > No, much simpler: _always_ append _a_single_ arch-specific extension, > and try loading that. We should document that extension; using the > one that is used by default by the compiler for producing shared > libraries should be good enough, I think. It's not so simple, though, as just .so vs. .dll. MacOS for example uses .dylib. And I think AIX does something else weird that I've forgotten about. Others probably do as well. 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. On Mon, 2013-04-29 at 23:13 +0300, Eli Zaretskii wrote: > > the same way one creates 1 makefile that can build the same code for 2 > > operating systems - something done every day. You make it up. You run > > uname with $(shell) or you pass in an argument from a top level script that > > does know the platform or whatever. In the end you have a bit of makefile > > that says: > > First, there's no uname on Windows. You are in fact saying that in > order to run a Makefile one would need something similar to autoconf. 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). Which is kind of beside the point, but just a thought :-). ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: dynamic object searching (was: Re: Dynamic objects)
On Mon, Apr 29, 2013 at 4:34 PM, Paul Smith 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? > 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. -David ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: dynamic object searching (was: Re: Dynamic objects)
On Mon, 2013-04-29 at 17:00 -0400, David Boyce wrote: > On Mon, Apr 29, 2013 at 4:34 PM, Paul Smith 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) ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: dynamic object searching (was: Re: Dynamic objects)
On Mon, Apr 29, 2013 at 7:53 PM, Paul Smith wrote: > Well, David, when you suggested it I wasn't so sure. But now that I've > thought of it myself... brilliant!! :-p :-) But now I'm having second thoughts ... -David ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: dynamic object searching (was: Re: Dynamic objects)
> ... or VMS shell (whatever that is) ... it was called DCL (Digital Command Language, I suspect) and the one feature I remember clearly is its help. If you typed "help" at the prompt, it was actually *helpful* in response. I have not seen that since. Eddy. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch)
Eli: >> cc fred.c -c -o fred.o >> cc bob.c -c -o bob.o >> error on line 20 -X >> error on line 30 - >> error on line 330 - >> makefile:342: recipe for target 'fred.o' failed >> makefile:350: recipe for target 'bob.o' failed > You need to look in both anyway. That is true of the very specific example Tim had given, in response to a particular objection which his example did genuinely address. Think for a moment longer and you shall see that there are other cases where your answer won't apply. The interleaved output from make -j n is often much harder to read. (When the output isn't even line-interleaved, but has some command's output starting part way through a line of the output of another command, life gets even harder.) Even in the specific example: on which file should I be looking at line 20, at line 30, or line 330 ? The answer "look in every failing file for every failing line number" scales quadratically, which is not good. Even when I know which line a message relates to, it can be hard to work out how that message relates to that line (especially if there's a preprocessor involved and the "undefined symbol xxyyz" relates to a line in which xxyyz never appears, but only arises after expansion of a mess of macros). It gets nasty fast to have to look in several files, at line 30 of each, and work out which of them is the one - relates to; and it gets easy to end up mistaking which one it relates to and "fixing" the wrong one. In a make with -j 12ish compiling many files, the starts and ends of compiles interleave with one another and with the output of running commands. Some of that output is errors, which (if the commands being run are well-behaved - not always true) shall mean the affected files are named by make in the output when they finish. Some output is warnings, that may actually be important, but the command succeeds: there's no marker indicating the end of a file that succeeds, so there are many files that warning might have come from; most likely one of those started recently, but not always easy to tell which. When hundreds of files are compiling - why else use -j 12ish ? - it can get hard to keep track of which are currently active at any given line of output, even when every file has both start and end markers for its output, e.g. if some files take much longer than others. The output from make -j several is hard to make sense of. Your shiny new feature really does sound (I haven't had occasion to try it) like a vast improvement. That *is* a strong case for turning it on by default. Naturally, before doing so, it's important to do ample testing: and one way to do that is to initially release make with it off by default but available, so that lots of folk can try it and give you feed-back. All the same, once it's been well tested, if no serious problems arise (and aren't fixed by your collective ingenuity) this is a good thing to turn on by default. Philip >>> "Doctor, my hammer has a head so large that I always hit my thumb" >>> "Throw out that hammer and get a non-broken one" >>> >>> The GNU tool working around the brokenness of some non-free software? >>> Some would call that collaboration in retaining your chains. This problem doesn't arise exclusively with non-free software, so this is an emotive argument, an appeal to bad example. Programmers, generally, are slap-dash about the things they throw together to build the software they're so proud of having (in their own opinions) written so nicely and well. They throw together shell scripts to wrap the compiler with some other commands that they also want to run on the same files, or that they need run before handing off their output to the compiler (e.g. they invented their own way of doing localisation, because it's so much more fun to reinvent the wheel than learn to use gettext): and they're profoundly negligent of error-reporting "because it's always worked for me" so anyone else inheriting their code is stuck with the results. They write contorted shell-scripts inline in the make-file as the command for a rule, using the "[ condition ] && action" short-hand for "if [ condition ]; then action; fi" and tack on "|| true" to avoid having make report the command as failed when [ condition ] was false; so the rule never gets reported as failing, even when it does, but "that's OK, because the error messaeges tell you what failed". The hideous monstrosities of make files that get generated by "helper" scripts that "work round the deficiencies of make" (almost invariably, in fact, they work round the author's poor knowledge of how to use make well - but those who inherit the code are stuck with the results) end up doing perverse things that most on this list would never dream of. I'd love to answer that with "so replace the bad scripts and hideously wrapped (and warped) build system with something well written", but the poor bug-fixer who's inherited the code from the oh-so-clever author is stuck wi
Re: memory allocation
> From: Paul Smith > Cc: Eli Zaretskii , "bug-make@gnu.org" > Date: Mon, 29 Apr 2013 16:16:40 -0400 > > It's probably a good idea for make to provide a "gmk_free()" function > that will free memory returned to the plugin when it calls gmk_*() > functions such as gmk_expand(). Is that sufficient to deal with this > problem? Yes, I think so. > Suppose, for example, we enhanced gmk_expand() to take a buffer and a > plugin invoked: > > gmk_expand(buf, buflen, "$(info expanding) $(FOO)"); > > This will return the expansion of the FOO variable, but it will ALSO > print "expanding" as the result of calling the info function. Now > suppose that the result of expanding $(FOO) was too large to fit into > buf, so the function returns the length needed and the plugin > reallocates the buffer to be large enough and re-invokes gmk_expand()... > now it will print "expanding" AGAIN. This could be solved, but I think providing gmk_free is much simpler and will suffice. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: dynamic object searching (was: Re: Dynamic objects)
> From: Paul Smith > Cc: Tim Murphy , bug-make@gnu.org > Date: Mon, 29 Apr 2013 16:34:01 -0400 > > On Mon, 2013-04-29 at 22:34 +0300, Eli Zaretskii wrote: > > > > Yes, that should be possible. My concern is that, at least on UNIX, the > > > rules for this are complex and I don't want to reimplement the runtime > > > linker :-). Maybe something like, first try the path as given and if > > > that fails, try adding arch-specific extensions? > > > > No, much simpler: _always_ append _a_single_ arch-specific extension, > > and try loading that. We should document that extension; using the > > one that is used by default by the compiler for producing shared > > libraries should be good enough, I think. > > It's not so simple, though, as just .so vs. .dll. MacOS for example > uses .dylib. And I think AIX does something else weird that I've > forgotten about. Others probably do as well. > > 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. OK, how about a lesser solution: have a builtin variable, say $SOEXT, which will have a platform-specific default extension of shared objects? Then whoever wants to use it for a portable Makefile, could do that, and people who want to use .gmkso can do that, too. WDYT? > It's probably a good idea to have make predefine a variable containing > the "host" architecture, to avoid the need for uname. That's a good feature regardless, but I think we should provide some solution for the extension as well. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: dynamic object searching
> From: Paul Smith > Cc: Eli Zaretskii , bug-make > Date: Mon, 29 Apr 2013 19:53:26 -0400 > > 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) I think the issues you raise are in addition to make_host. make_host should just say "ms-windows" or "ms-dos" (_not_ the same) or "cygwin" or "gnu/linux" etc. This is enough to determine things like $EXEEXT etc. We could then make more feature variables, like posix etc., or maybe a system_features variable that is a list, which could be used to fine-tune the Makefile. (For knowing what shell is available one can simply use $SHELL, so I'm not sure anything else is needed.) And what about make_version? ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
