-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
acado/1.2.2 #3967
acado/1.2.2 #3967
Conversation
Failure in build 1 (
|
Some configurations of 'acado/1.2.2' failed in build 2 (
|
recipes/acado/all/conandata.yml
Outdated
@@ -0,0 +1,4 @@ | |||
sources: | |||
"1.2.2": |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"1.2.2": | |
"1.2.2beta": |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can conan package version contain letters?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried it out locally, and I got the following line for a find_package(ACADO 1.2.2 REQUIRED)
:
-- Found ACADO: 1.2.2beta (found suitable version "1.2.2beta", minimum required is "1.2.2")
I recently had problems with a lib that had a v
prefix (like v39
), and conan made set(LIB_VERSION "39")
out of it, so CMake was not able to determine if the version is correct. Also filed an issue, and eventually ended up in doing it properly 😅
TL&DR: Is it safe to deviate from strict semantic versioning? According to SEMVER we should at least a add a dash, what do you think?
EDIT: I tried it out, it works, so should we go for 1.2.2-beta
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TL&DR: Is it safe to deviate from strict semantic versioning?
100% CCI even has a costume virtual release notation cci.yymmdd
for projects which do not have releases of are no longer maintained or outputting releases.
According to SEMVER we should at least a add a dash, what do you think?
EDIT: I tried it out, it works, so should we go for 1.2.2-beta ?
I personally think it's better to use the original upstream notation, it makes it easier to find what you want as a consumer.
However correcting the notation to be standard is also a nice thought
There's no rule (yet) so we'll see what the Conan team requests.
Perhaps a new topic for an official policy? /cc @jgsogo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typically in CCI we do not like to use the "external/third party/vendored" sources because this prevents the consumer from having control over which version is used... worst of all it usually leads to duplication which makes life very painful.
Since you have #3962 you can add a requirement... but you'll need to remove this line https://github.com/acado/acado/blob/b4e28f3131f79cadfd1a001e9fff061f361d3a0f/CMakeLists.txt#L204 and patch the project...
Maybe not worth it 🤔 since all the other dependencies are just a complicated
eigen3
is a very common dependency, I am not sure if it's even being used 😖 but perhaps that would be from CCI as well?
Also I see they install the "external_packages" which is very odd... not sure it that will cause problems since they hard code the path
I totally get it. This library is not the cleanest, and I think it is out of active development. #3962 might not be usable here as the version used in ACADO customized for embedded targets. Yes, everything is hardcoded and not really easy to modularize. See it positive, the package has no dependencies 🤦♂️ 😄 |
Failure in build 3 (
|
Failure in build 4 (
|
Some configurations of 'acado/1.2.2-beta' failed in build 5 (
|
Some configurations of 'acado/1.2.2-beta' failed in build 6 (
|
Recipe syntax error in build 7:
|
Some configurations of 'acado/1.2.2-beta' failed in build 8 (
|
Some configurations of 'acado/1.2.2-beta' failed in build 9 (
|
Some configurations of 'acado/1.2.2-beta' failed in build 10 (
|
@blackliner I can confirm the error, clang 9 doesn't work. I would report to the upstream and skip it for this version. It works for Clang 10. |
Co-authored-by: Uilian Ries <uilianries@gmail.com>
Some configurations of 'acado/1.2.2-beta' failed in build 31 (
|
@uilianries I get a reproducible segfault with this combo, shall I disable this specific build? |
Some configurations of 'acado/1.2.2-beta' failed in build 32 (
|
In my experience if it's only shared and gcc failing it's an fPIC problem... bit I see that's an issue with the upstream cmake. |
You mean that the STATIC targets that get linked into the main SHARED lib would need fPIC, but do not get it? Is this a case for a patch? There is an option fPIC, what is this one then used for if it does not help us here? Also, usually you would get linker errors when fPIC is missing, right? |
Some configurations of 'acado/1.2.2-beta' failed in build 33 (
|
The builds do work with Any ideas left? |
Yes looking at the logs it builds two targets, one is always static and it's possible that it's missing the fPIC which, sometimes is a link issue, but on larger complicated projects nasty ABI surprises can happen at runtime. ➡️ Just block the older C++ ABI on gcc. If someone really needs it they'll have to add it. I think this is more than enough work for the time being... it does not need to be perfect having it is better than nothing! |
I had all of that earlier, but @uilianries did not want that 😞 #3967 (review) |
An unexpected error happened and has been reported. Help is on its way! 🏇 |
Acado seems be limited. I'm fine if we need to skip those configurations. Let's wait for CCI result. |
All green in build 35 (
|
Specify library name and version: acado/1.2.2
Some whacky codegenerator stuff going on, appreciate feedback for my solution.
conan-center hook activated.