[bug #27609] Stupid inference rule for yacc files can clobber C sources!

[Paul D. Smith]

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 with .SUFFIXES: will break that.

Please see the GNU make manual section on suffix rules.  First, when defining
suffixes you add them one suffix at a time, not as a group (use ".o" and ".c",
not ".o.c", for example).  Second, suffixes as .SUFFIXES: prerequisites only
_adds_ to the existing suffix list, it doesn't _replace_ the existing suffix
list.

If you're trying to keep only some of the rules then first you have to turn
them all off, then add back just the ones you want:


.SUFFIXES:
.SUFFIXES: .c .o




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #27609] Stupid inference rule for yacc files can clobber C sources!

[Kaz Kylheku]

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 no recipe.

I then added .o.c to suffixes, in hopes that  this would turn on rules
involving .o and .c files only.

The lex.yy.o: lex.yy.c rule now started to work again.

But alas, the bad rule now kicked in!

$ make
lex -i -8 hc.l
cc -g -Wall -W -ansi -D_XOPEN_SOURCE=500-c -o lex.yy.o lex.yy.c
lex.yy.c:4548:17: warning: ‘yyunput’ defined but not used
[-Wunused-function]
lex.yy.c:4589:16: warning: ‘input’ defined but not used
[-Wunused-function]
lex  -t hc.l > hc.c   <--- HUH?

Is that a bug? This is make 3.81 on Ubuntu 11.04.

If not, what is the real way to put the through the heart of this beast (and
anything like it, known or unknown), without losing the useful implicit
rules?

How can I say, "I want only the implicit rules which involve only these file
types and do not involve any other file types."

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: make check under Cygwin

[Paul Smith]

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 above the 
> same test is done. This looks strange.

It's not beautiful code, but it's not wrong.  However I rewrote this
function to be more clear.

> 2) In connection with (1) above, the category 'default_names' produces
> '*** Test returned 0' and this is considered to be $suite_passed = 0
> (no deletion of files, no incrementation of categories_passed etc.),
> however the category seems to pass since the "ok" string is printed.
> 
> If i apply (1) above, all is ok.
> I don't understand why this "Test returned 0" does not show up
> on other (eg Linux) platforms.

There is a bug in default_names; it's missing the final "1;".  That
means that the result of the last thing in that file will be used as the
return.  For case-sensitive filesystem versions of make that's an
unlink() which succeeds.  For case-insensitive filesystem versions of
make it's the if-statement test, which is false.

I've fixed default_names.

> 3) If the HOME env var is not set, one of the jobserver tests fails.
> Perhaps this test should not be launched if HOME is not set.

I changed this test to not require $HOME.



___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #27609] Stupid inference rule for yacc files can clobber C sources!

[Paul D. Smith]

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 cannot be blamed on POSIX.

I recommend getting into the habit of adding a ".SUFFIXES:" target to your
makefiles to disable the built-in suffix rules, so that the worst that can
happen if your rules fail to apply for some reason is that make complains it
doesn't know how to build the target.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #27609] Stupid inference rule for yacc files can clobber C sources!

[Kaz Kylheku]

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


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #27609] Stupid inference rule for yacc files can clobber C sources!

[Kaz Kylheku]

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.

All of a sudden though, for some reason, an internal rule in make kicked in
and did this:

   lex -t hc.l > hc.c

oops, my source file is gone; all I have is the most recent git repo copy
which doesn't have all my recent work.

Is this is another POSIX-required misfeature?

This is the sort of thing for which Stallman invented --posix-me-harder.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: "load" on Windows

[Gisle Vanem]

"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 *fname, int argc, char **argv);
 } fptr;


Okay, you're right. I didn't see the "union".


Thanks.  Your problem is here:


  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
seems.  Here's why:


Ayyy!! > 1 day wasted on such a triffle. May I suggest more warnings
in define_new_function()? It works fine as "$(hello-world "Hello world").


Btw, Gisle, I don't understand why you needed to use the EXPORT
thingy, the DLL is compiled just fine without it, and only exports
non-static variables and functions anyway. 


Right again. I was thinking more about making a DLL with MSVC.
(without any .def file).

Thanks again.

--gv

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #33138] .PARLLELSYNC enhancement with patch

[David Boyce]

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 Eli for pushing it over the goal line!

More than anything I'll be happy to see this thread die of natural causes,
since it's going on ~2.5 years with an embarrassing misspelling by me in
the subject line.

David
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: "load" on Windows

[Paul Smith]

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
> seems.  Here's why:
>   /* Look up a function by name.  */
> 
>   static const struct function_table_entry *
>   lookup_function (const char *s)
>   {
> const char *e = s;
> 
> while (*e && ( (*e >= 'a' && *e <= 'z') || *e == '-'))  
>   e++;
> 
> So if you name your function hello-world instead, it will work.
> 
> Paul, if this limitation is deliberate, I suggest to document it where
> we explain the arguments of gmk_add_function.

It's not so much a deliberate restriction, as it was a performance
improvement I added in 2002 along with the switch to hash table lookups,
and completely forgot about afterward :-).  All the existing make
functions were lowercase and contained only '-', so we avoided the
lookup effort if we found a name which could not be a function.

Now that users can define their own functions, I don't think that
restriction is appropriate anymore.  I'll fix this, thanks.

> (I can make these changes in documentation, if you agree.)

I have a vivid memory of adding documentation regarding this so let me
look around for it.


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: "load" on Windows

[Eli Zaretskii]

> 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 awfully ascii-ish anyway? Can it use isalpha() or some similar
> abstraction instead?

isalpha won't cut it, we probably need to test islower as well.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: "load" on Windows

[David Boyce]

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 mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: "load" on Windows

[Eli Zaretskii]

> 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 requirements from the function that implements the
Make function added by a loaded object.  If the reader looks at
gnumake.h, she will see that the function's signature should be like
this:

  char *(*func)(const char *nm, int argc, char **argv)

But this had better be documented explicitly in the manual.

More importantly, we never say that the 'char *' value returned by the
extending function must either be a pointer to a buffer allocated by
calling gmk_alloc, or NULL; any other kind of pointer will cause
unexpected results or crashes, because Make will try to free any
non-NULL pointer returned by the extension.  I think it is quite
important to describe this in the manual.

(I can make these changes in documentation, if you agree.)

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: "load" on Windows

[Eli Zaretskii]

> 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 the test suite, to
> > see what's different.
> 
> Well this is just silly. I've added tracing code a lot of places (enabled
> by option --trace) . I do see my mk_test_gmk_setup() gets called, but not 
> the new function added by gmk_add_function(). 
> 
> gmk_add_function() calls define_new_function(), but therein I see a:
>   ent->fptr.alloc_func_ptr = func;
> 
> 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 *fname, int argc, char **argv);
  } fptr;

> How else is the new function supposed to be called? I don't understand
> this contorted logic.

I don't understand the question, sorry.  The logic looks quite simple
to me: In expand_builtin_function we have:

  if (!entry_p->alloc_fn)
return entry_p->fptr.func_ptr (o, argv, entry_p->name);

  /* This function allocates memory and returns it to us.
 Write it to the variable buffer, then free it.  */

  p = entry_p->fptr.alloc_func_ptr (entry_p->name, argc, argv);
  if (p)
{
  o = variable_buffer_output (o, p, strlen (p));
  free (p);
}

For loaded functions, define_new_function has this:

  ent->alloc_fn = 1;
  ent->fptr.alloc_func_ptr = func;

So expand_builtin_function should see that alloc_fn is non-zero, and
invoke your function via the alloc_func_ptr pointer.

> For reference, here is my complete mk_test.c:

Thanks.  Your problem is here:

>   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
seems.  Here's why:

  /* Look up a function by name.  */

  static const struct function_table_entry *
  lookup_function (const char *s)
  {
const char *e = s;

while (*e && ( (*e >= 'a' && *e <= 'z') || *e == '-'))  
  e++;

So if you name your function hello-world instead, it will work.

Paul, if this limitation is deliberate, I suggest to document it where
we explain the arguments of gmk_add_function.

Btw, Gisle, I don't understand why you needed to use the EXPORT
thingy, the DLL is compiled just fine without it, and only exports
non-static variables and functions anyway.  Doing away with it makes
the code portable to platforms other than Windows.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: "load" on Windows

[Gisle Vanem]

"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 tracing code a lot of places (enabled
by option --trace) . I do see my mk_test_gmk_setup() gets called, but not 
the new function added by gmk_add_function(). 


gmk_add_function() calls define_new_function(), but therein I see a:
 ent->fptr.alloc_func_ptr = func;

What about setting:
 ent->fptr.func_ptr = func;

too? How else is the new function supposed to be called? I don't understand
this contorted logic. Isn't a new function supposed to extend (and possibly
modify) the 'function_table' used from expand_builtin_function()? Thus 
possibly replacing a built-in? Please somebody clarify.


For reference, here is my complete mk_test.c:

 #include 
 #include 
 #include 
 #include 
 #include 
 #include "gnumake.h"

 #define EXPORT __declspec(dllexport)

 EXPORT int plugin_is_GPL_compatible;

 static char *hello_world (const char *func_name, int argc, char **argv)
 {
   char *buf = gmk_alloc(1000), *p = buf;
   int  i;

   fprintf (stdout, "hello_world() called: %s\n", func_name);

   for (i = 0; i < argc; i++)
   {
 fprintf (stdout, "argv[%d]: %s\n", i, argv[i]);
 p += sprintf (p, "%s+", argv[i]);
   }
   return (buf);
 }

 EXPORT int mk_test_gmk_setup (const gmk_floc *flocp)
 {
   gmk_add_function ("hello_world", hello_world, 0, 255, 0);
   fprintf (stdout, "\"%s()\" called from %s (%lu)\n",
__FUNCTION__, flocp->filenm, flocp->lineno);
   return (1);
 }

--gv



___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make