Follow-up Comment #12, bug #27609 (project make):
It's hard to diagnose problems based on general descriptions. Please provide
specific examples of what you did and what the result was.
However, it's definitely true that if you're relying on some of the built-in
rules then turning them all off w
Follow-up Comment #11, bug #27609 (project make):
I tried .SUFFIXES: but now make tried to build the program even though
lex.yy.o is a prerequisite, and is missing, without any complaints. This is,
of course, because I have a rule which gives a dependency from lex.yy.o to
lex.yy.c, but which has n
On Wed, 2013-09-25 at 11:30 +0200, Denis Excoffier wrote:
> Still experimenting 'make check' with Cygwin (without the spawn-patch,
> with --disable-load):
>
> 1) In test_driver.pl, line 486 (look for "Test returned"), a comparison
> of $code against the value -1 is performed. However, 3 lines abov
Follow-up Comment #10, bug #27609 (project make):
Yes, both .y.c and .l.c suffix rules are required by the POSIX standard.
However, they've been present in GNU make for over 20 years, since before
POSIX standardized make, so while POSIX requirements are one reason to keep
them, their existence ca
Follow-up Comment #9, bug #27609 (project make):
What if these dangerous implicit rules made a rotating backup of their victim?
What is the downside?
mv foo.c.keep.1 foo.c.keep.2
mv foo.c foo.c.keep.1
mv y.tab.c foo.c
___
Repl
Follow-up Comment #8, bug #27609 (project make):
I was just burned by this again! I have a small project with "hc.l" lexer, and
a "hc.c" source file. It's been working fine.
My Makefile was generating lex.yy.c from hc.l, compiling hc.c to hc.o, and
lex.yy.c to lex.yy.o, and linking everything.
"Eli Zaretskii" wrote:
What about setting:
ent->fptr.func_ptr = func;
too?
They are one and the same, since they are members of a union:
struct function_table_entry
{
union {
char *(*func_ptr) (char *output, char **argv, const char *fname);
char *(*alloc_func_ptr) (const char *fn
On Mon, Sep 30, 2013 at 3:12 PM, Frank Heckenbach
wrote:
> I tested the new version and found no new issues, so as far as I'm
> concerned this feature can now be considered finished. Thanks for
> the initial patch, David, and the integration into GNU make, Paul!
>
And special thanks to Frank and
On Sat, 2013-10-05 at 16:34 +0300, Eli Zaretskii wrote:
> > EXPORT int mk_test_gmk_setup (const gmk_floc *flocp)
> > {
> > gmk_add_function ("hello_world", hello_world, 0, 255, 0);
> ^^^
> Make functions cannot have the '_' character in their names, so it
>
> Date: Sat, 5 Oct 2013 10:22:13 -0400
> From: David Boyce
> Cc: Gisle Vanem , Paul Smith , bug-make
>
>
>
> [1:text/plain Hide]
>
> On Sat, Oct 5, 2013 at 9:34 AM, Eli Zaretskii wrote:
>
> > while (*e && ( (*e >= 'a' && *e <= 'z') || *e == '-'))
> >
>
> Isn't this awfull
On Sat, Oct 5, 2013 at 9:34 AM, Eli Zaretskii wrote:
> while (*e && ( (*e >= 'a' && *e <= 'z') || *e == '-'))
>
Isn't this awfully ascii-ish anyway? Can it use isalpha() or some similar
abstraction instead?
-David Boyce
___
Bug-make
> Date: Sat, 05 Oct 2013 16:34:11 +0300
> From: Eli Zaretskii
> Cc: bug-make@gnu.org
>
> Paul, if this limitation is deliberate, I suggest to document it where
> we explain the arguments of gmk_add_function.
One other important thing that doesn't seem to be covered in the
manual is the requireme
> From: "Gisle Vanem"
> Date: Sat, 5 Oct 2013 14:33:26 +0200
>
> "Eli Zaretskii" wrote:
>
> > Well, the tests in the test suite that test this feature did work for
> > me at some point, so you may wish first to verify they do for you, and
> > then compare your extension with the ones used by th
"Eli Zaretskii" wrote:
Well, the tests in the test suite that test this feature did work for
me at some point, so you may wish first to verify they do for you, and
then compare your extension with the ones used by the test suite, to
see what's different.
Well this is just silly. I've added tr
14 matches
Mail list logo
