Thread of 4 posts
jump to replies
>blender removes ceres+eigen from tree expecting you to provide system versions
>fine, package ceres which we didn't have, we already had eigen
>build fails mysteriously
>turns out the commit that removed eigen also "refactored" some invocations of some eigen stuff to syntax that is seemingly not compatible with any existing version of eigen
??? what are they doing
https://gist.github.com/q66/40bb8eed351e76ae4807833d7005fc67 patch that fixes it for reference
i could not find any issue or anything for this anywhere
ah, i figured it out
they added a second invocation that uses a template parameter in eigen 5.0 (which nothing really uses yet, and e.g. ceres, the other dep which they removed, does not compile against it in its latest tag)
this is a mess but at least it's explained
ofc the `const int Options = ...` and then passing it to a template arg is still invalid but i guess gcc will eat it because gcc eats a lot of invalid stuff
yay, more fun patches
https://gist.github.com/q66/370af5e96d5faf1ccebcf603d9ff3268
i wonder how many more until it finishes
6 visible replies; 4 more replies hidden or not public
back to top
@q66 oh it's an "extencion", I see
@TheOneDoc it's just stuff gcc eats, not really a documented extension, same with e.g. `strlen("foo")` being accepted in constant expressions in gcc because the frontend will fold it as a known thing resolvable at compile time, even though it is not, semantically
clang is a lot more strict and will not eat such things
@q66 @TheOneDoc imean clang probably also folds it the same way but like . its good that it errors
@fiore @TheOneDoc well of course it will, technically
but yeah it should be an error
i suspect that this is some deficiency in gcc's design/layering that prevents it from erroring due to losing information, but i may be wrong
@q66 @TheOneDoc something something gcc moment