> 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
> 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 reimple
> 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
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 s
> ... 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.
_
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
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 assumptio
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 th
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,
> 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.
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 call
> 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 - s
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,
> 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_
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
> 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 '
> 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
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
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 wit
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 ham
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 writ
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
> 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' f
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 portabilit
> 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
> 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 be
> 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
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 th
> 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
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
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
32 matches
Mail list logo
