Weird errors on alternative build
Opened this issue · 5 comments
In my fork, I've moved things around a bit to enable a regular Max package type build with max-sdk-base as a submodule.
On my first attempt to compile, I got the following error:
~/src/scheme-for-max/source/projects/s4m/s4m-grid.c:302:60: error: cannot take the address of an rvalue of type 't_object *' (aka 'struct object *')
t_max_err err = hashtab_lookup(s4m_arrays, array_name, &(t_object *)array);
^~~~~~~~~~~~~~~~~~I think this is a valid error, it should be (consistent with this similar case):
t_max_err err = hashtab_lookup(s4m_arrays, array_name, (t_object **)&array);If the above is fixed, then I get a bunch of errors and even more warnings (which are omitted to reduce the noise):
^
~/src/scheme-for-max/source/projects/s4m/s4m.c:2087:56: error: cannot take the address of an rvalue of type 't_object *' (aka 'struct object *')
hashtab_lookup(s4m_arrays, gensym(array_name), &(t_object *)array);
^~~~~~~~~~~~~~~~~~
// ... (lots of warnings)
^
~/src/scheme-for-max/source/projects/s4m/s4m.c:2316:9: error: void function 's4m_bang' should not return a value [-Wreturn-type]
return defer(x, s4m_callback_bang, NULL, 1, ap);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// ... (lots of warnings)
^
~/src/scheme-for-max/source/projects/s4m/s4m.c:2360:9: error: void function 's4m_int' should not return a value [-Wreturn-type]
return defer(x, s4m_callback_int, NULL, 2, ap);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~/src/scheme-for-max/source/projects/s4m/s4m.c:2427:9: error: void function 's4m_float' should not return a value [-Wreturn-type]
return defer(x, s4m_callback_float, NULL, 2, ap);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^
~/src/scheme-for-max/source/projects/s4m/s4m.c:2508:13: error: void function 's4m_list' should not return a value [-Wreturn-type]
return defer(x, s4m_callback_list, s, argc + 1, ap);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^
~/src/scheme-for-max/source/projects/s4m/s4m.c:2584:9: error: void function 's4m_eval_string' should not return a value [-Wreturn-type]
return defer(x, s4m_s7_eval_string, s, 0, NULL);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^
~/src/scheme-for-max/source/projects/s4m/s4m.c:2816:17: error: void function 's4m_msg' should not return a value [-Wreturn-type]
return defer(x, s4m_callback_msg_inlet_0, s, argc, argv);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^
~/src/scheme-for-max/source/projects/s4m/s4m.c:2818:17: error: void function 's4m_msg' should not return a value [-Wreturn-type]
return defer(x, s4m_callback_msg_inlet_1, s, argc, argv);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^
~/src/scheme-for-max/source/projects/s4m/s4m.c:2820:17: error: void function 's4m_msg' should not return a value [-Wreturn-type]
return defer(x, s4m_callback_msg_inlet_2, s, argc, argv);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^
~/src/scheme-for-max/source/projects/s4m/s4m.c:2822:17: error: void function 's4m_msg' should not return a value [-Wreturn-type]
return defer(x, s4m_callback_msg_inlet_3, s, argc, argv);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^
~/src/scheme-for-max/source/projects/s4m/s4m.c:2824:17: error: void function 's4m_msg' should not return a value [-Wreturn-type]
return defer(x, s4m_callback_msg_inlet_4, s, argc, argv);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^
~/src/scheme-for-max/source/projects/s4m/s4m.c:2826:17: error: void function 's4m_msg' should not return a value [-Wreturn-type]
return defer(x, s4m_callback_msg_inlet_5, s, argc, argv);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
133 warnings and 20 errors generated.
make[3]: *** [source/projects/s4m/CMakeFiles/s4m.dir/s4m.c.o] Error 1
make[2]: *** [source/projects/s4m/CMakeFiles/s4m.dir/all] Error 2
make[1]: *** [all] Error 2
make: *** [build] Error 2The first of this batch is similar to the initial error and easily fixable but the others, well it looks like there's a general pattern of widely using return defer(..) and return schedule(...) in void functions.
Do you have any insight about what may be the issue here?
Hi, yes it definitely needs warning cleanup! Thanks for working on this. I would be happy to cut the main version over to your fork if you manage to clean it up and get it building better. When I started the project my C chops were very rusty, and the SDK was not using the new build system, so there is lots of cruft.
Regarding the defer calls: that is the function call to defer the message to the low thread. I guess you have a different error threshold on your compiler than I was working with. I don't have capacity to dig into this at the moment, but I suspect that all is needed is for it each of those to be changed to a call to defer and then a void return. The reason all of those exist is to support having the external run in only one thread - those calls put scheduler thread messages on to the main thread queue. It's not elegant but seems to work properly.
When you get your fork doing what you'd like please let me know so I can help you test it! There is an automated test patch too.
Here is the relevant docs page: https://cycling74.com/sdk/max-sdk-7.3.3/group__threading.html#gaa24a0c9896f1ad241e45590065c3f643
I see that defer is actually returning a void pointer rather than void, that must be the root of my error! Perhaps a cast on those is all that is required?
Hi Iain
Glad to help as much as I can.
To that end, I've managed to fix the errors referred to above in my last commit and brought down the warnings from 399 to 327, but the result remains untested. The rest of the warnings are somewhat application specific and so require your attention. I've dumped them to a file and they are attached below:
Hi Shakeeb, most of the warnings, in case you feel inclined to chip away at more, are just cast issues. I started originally copying the s7 docs which eliminated the verbose casts. So you can see some places where I have them and others (most) don't, typically for going back and forth from the s7_pointer type to max's types, or C types.
It is also probably now at the size where header declarations should have gone in their own file!
Would it make sense for you to move your work to a branch on the main repo so we can test and merge more easily? I'm happy to add you as a commiter.
Hi Iain
Would it make sense for you to move your work to a branch on the main repo so we can test and merge more easily? I'm happy to add you as a commiter.
Thank Iain. Feel free to copy the current fork to a branch on your main repo. I'd love to help more but outside of my day job, I'm in the middle of a repo spring clean which is leaving me with little spare bandwidth right now.