cmake for hpmpc and blasfeo? #61
Comments
|
Cool! But shouldn't this be an issue in the respective hpmpc and blasfeo
repo's ?
Anyway, this would indeed be very helpful, so please (if @giaf agrees) push
for it.
…On Tue, 11 Apr 2017 at 11:20 zanellia ***@***.***> wrote:
I had some troubles managing ExternalProjects based on Makefiles from
CMake so I made a minimal port of hpmpc's build system to CMake. Not sure
this is better than a Makefile-based build system, but at least all our
core code is going to be built with CMake (good? dunno). Anyways, if you
guys like it we could give it a shot. The code is here:
I <https://github.com/zanellia/hpmpc/tree/crosscompiling>
and it is based on a single CMakeLists.txt file (unlike the previous
hpmpc's CMake build system)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#61>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABXrjB5WDzCb7NU9Iw-DBkZPuMzvX8Beks5ru8SGgaJpZM4M6d7U>
.
|
|
As @giaf is not a big fun of cmake, I thought I could start an acados-based discussion here to convince him :P |
|
Alles klar ;) We would have the following advantages (to name a few):
- Compatibility of compiler flags across projects, but you could even
set different ones if you would want to,
- Choosing which 'mode' for blasfeo from the top level CMakelists.txt in
acados,
- Build targets like make clean etc. would translate more easy to the
external projects.
Actually, it makes sense to do the same for qpOASES.
…On Tue, 11 Apr 2017 at 11:37 zanellia ***@***.***> wrote:
As @giaf <https://github.com/giaf> is not a big fun of cmake, I thought I
could start an acados-based discussion here to convince him :P
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#61 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABXrjFhKj6mqqiSg8qxQcUeiciPVdu1jks5ru8hXgaJpZM4M6d7U>
.
|
|
@ghorn already uses CMake for qpOASES actually...(hint) |
|
I prefer make, since for some low-level chips the toolchain supports Make
instead of Cmake.
Anybody forsee difficulties for compiling the whole acados with make?
On Apr 11, 2017 20:37, "zanellia" <notifications@github.com> wrote:
As @giaf <https://github.com/giaf> is not a big fun of cmake, I thought I
could start an acados-based discussion here to convince him :P
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#61 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AIX0c5MRi6y3bnixQIp__VTmxt_YqY7tks5ru8hXgaJpZM4M6d7U>
.
|
|
It's a lot of manual labor, CMake automates a lot of that.
I'm sure there are workarounds for those low-level chips, e.g. you could
specify a specific build type for them (CMAKE_BUILD_TYPE).
Could you give an example of what such a toolchain would look like?
…On Tue, 11 Apr 2017 at 11:44 doanminhdang ***@***.***> wrote:
I prefer make, since for some low-level chips the toolchain supports Make
instead of Cmake.
Anybody forsee difficulties for compiling the whole acados with make?
On Apr 11, 2017 20:37, "zanellia" ***@***.***> wrote:
As @giaf <https://github.com/giaf> is not a big fun of cmake, I thought I
could start an acados-based discussion here to convince him :P
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#61 (comment)>, or
mute
the thread
<
https://github.com/notifications/unsubscribe-auth/AIX0c5MRi6y3bnixQIp__VTmxt_YqY7tks5ru8hXgaJpZM4M6d7U
>
.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#61 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABXrjGVN939Mv_MEx6NTZpJS1tNGsyrLks5ru8ojgaJpZM4M6d7U>
.
|
|
Hey Dang, in my limited experience, build systems can be a pain. CMake might help to manage builds as the project(s) grows in complexity.
I would be also interested in knowing more about practical problems, if you are facing some already. I guess you could encounter problems whenever you have to use some high-level IDE or environment right? Otherwise you just need to have CMake installed on your host machine, configure the project and cross-compile, right? |
|
This toolchain using Make is what I have worked with:
https://github.com/espressif/esp-idf/blob/master/make/project.mk
For each component, it specifies local additional make file.
On Apr 11, 2017 20:50, "Robin Verschueren" <notifications@github.com> wrote:
It's a lot of manual labor, CMake automates a lot of that.
I'm sure there are workarounds for those low-level chips, e.g. you could
specify a specific build type for them (CMAKE_BUILD_TYPE).
Could you give an example of what such a toolchain would look like?
On Tue, 11 Apr 2017 at 11:44 doanminhdang ***@***.***> wrote:
I prefer make, since for some low-level chips the toolchain supports Make
instead of Cmake.
Anybody forsee difficulties for compiling the whole acados with make?
On Apr 11, 2017 20:37, "zanellia" ***@***.***> wrote:
As @giaf <https://github.com/giaf> is not a big fun of cmake, I thought I
could start an acados-based discussion here to convince him :P
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#61 (comment)>, or
mute
the thread
<
https://github.com/notifications/unsubscribe-auth/AIX0c5MRi6y3bnixQIp__
VTmxt_YqY7tks5ru8hXgaJpZM4M6d7U
>
.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#61 (comment)>, or
mute
MEx6NTZpJS1tNGsyrLks5ru8ojgaJpZM4M6d7U>
.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#61 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AIX0c8gSVdssygupP0ep9pZRpXc74Rjlks5ru8tbgaJpZM4M6d7U>
.
|
|
I do see the point in the sense that integrating acados directly into the toolchain might be tricky. However, you could also cross-compile a static or shared library for acados and just link against it from your Makefile-based build system. |
|
Hi Andrea,
Thanks for sharing your experiences, I also feel so.
My problem is that in order to fit with the code development framework of
the chip, I better use their settings for cross-compiling, which was
meticulously constructed with Make (https://github.com/espressif/esp-idf)
. It will compile the components of the freeRtos, then my own code, then
pack them into one binary file for flashing.
Currently I still didn't use the advanced feature that the toolchain
provides, eg. Make with component-wise makefile. My current tactics is to
put all the source files into one folder and (let the toolchain) run a
dirty make for it.
…On Apr 11, 2017 20:58, "zanellia" ***@***.***> wrote:
Hey Dang, in my limited experience build systems can be a pain. CMake
might help to manage builds as the project(s) grows in complexity.
Could you give an example of what such a toolchain would look like?
I would be also interested in knowing more about practical problems, if
you are facing some already. I guess you could encounter problems whenever
you have to use some high-level IDE or environment right? Otherwise you
just need to have CMake installed on your host machine, configure the
project and cross-compile, right?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#61 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AIX0c2DkOqa0mZSl0HNZDdQFl8HFBeA3ks5ru80SgaJpZM4M6d7U>
.
|
|
Thanks for the suggestion, Andrea. I'll check if such linking could be done
easily with my toolchain.
On Apr 11, 2017 21:06, "zanellia" <notifications@github.com> wrote:
I do see the point in the sense that integrating acados directly into the
toolchain might be tricky. However, you could also cross-compile a static
or shared library for acados and just link against it from your
Makefile-based build system.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#61 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AIX0c4eCmcLritqopDhb2K66Go7jPV1Uks5ru89HgaJpZM4M6d7U>
.
|
|
Yes I'm still a fan of make instead of cmake, nothing has changed in that regard ;) Make provides exactly what I want: a clean and low-level way to tell exactly how the project build should be, and where I know exactly what is going on (e.g. regarding dependencies). The flexibility provided by cmake is in my opinion a minus and not a plus, at least in the (low level) stuff I'm doing. That said, I'm not against adding to the make an additional cmake if this can make stuff easier in ACADOS. But this cmake should mimic exactly what the make does (e.g. fix the compiler to the ones that work, fix the compilation flags to the ones I know work well). But at this point I don't see any difference with respect to a make called using e.g. @zanellia thanks for the effort of adding a cmake. Note that BLASFEO HP doesn't work with any compiler other than gcc and clang, since the assembly-coded kernels can be processed only by these compilers. |
|
To be honest, @giaf might be totally right, although I still feel for
slightly larger projects (like acados) CMake might help to reduce
complexity. I agree that CMake is not very transparent sometimes, however
most of the time it does an OK job. What would you loose in terms of
control over the compiler's behavior with the simple CMake build system I
hacked together for example? You should be able to set compiler/linker
flags exactly the way you do it with a Makefile. Am I missing something?
As it is now, it only works when BLASFEO is used (when it is not, entirely
different sources are employed).
Yes, sorry, it is not meant to replace the Makefile-based build system at
all at the moment :)
2017-04-12 1:08 GMT-07:00 giaf <notifications@github.com>:
… Yes I'm still a fan of make instead of cmake, nothing has changed in that
regard ;)
Make provides exactly what I want: a clean and low-level way to tell
*exactly* how the project build should be, and where I know *exactly*
what is going on (e.g. regarding dependencies). The flexibility provided by
cmake is in my opinion a minus and not a plus, at least in the (low level)
stuff I'm doing.
That said, I'm not against adding to the make an additional cmake if this
can make stuff easier in ACADOS. But this cmake should mimic *exactly*
what the make does (e.g. fix the compiler to the ones that work, fix the
compilation flags to the ones I know work well). But at this point I don't
see any difference with respect to a make called using e.g.
make TARGET=X64_INTEL_HASWELL LA=HIGH_PERFORMANCE
@zanellia <https://github.com/zanellia> thanks for the effort of adding a
cmake.
As it is now, it only works when BLASFEO is used (when it is not, entirely
different sources are employed).
Note that BLASFEO HP doesn't work with any compiler other than gcc and
clang, since the assembly-coded kernels can be processed only by these
compilers.
HPMPC also doesn't work with e.g. visual studio (and I never tested with
anything else than gcc and clang). In my opinion, removing the list of
tested compilers to choose among is a kind of blind guess on what can
happen with other compilers.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#61 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AQCkfbxnI72otgUBJPIyAM3HqQ3g77Jyks5rvIaQgaJpZM4M6d7U>
.
|
|
@zanellia Maybe I can return the question to you :) What would such a CMake give more than the current makefile? What are the features that you would like to have? |
This is the main reason I hacked together a CMake build system for hpmpc. I personally find CMake easier and I would expect it to bring some advantages in the near future. Instead of comparing CMake and Makefile in terms of what functionalities they offer, I would focus on how easy it is to develop and maintain build systems based on the two approaches. |
|
What about discussing this once we are back to the office after Easter? |
|
Yea, sure! |
|
So, although I do like the idea of having all the external projects using CMake, as Gianluca pointed out, it might be difficult to keep Make- and CMake-based build systems in sync. This holds for hpmpc and blasfeo and it is even more of a relevant issue with other dependencies like qpOASES. Thoughts? |
|
Why would you want them to be in sync? With acados, we use the Makefile
generated by CMake, if you have hpmpc and/or blasfeo standalone you can
choose between this or the Makefile handwritten by @giaf.
…On Fri, 21 Apr 2017 at 07:26 zanellia ***@***.***> wrote:
So, although I do like the idea of having all the external projects using
CMake, as Gianluca pointed out, it might be difficult to keep Make- and
CMake-based build systems in sync. This holds for hpmpc and blasfeo and it
is even more of a relevant issue with other dependencies like qpOASES.
Thoughts?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#61 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABXrjEvBwCr4IdqW6fVyLbtYIvS3Lr8mks5ryLyngaJpZM4M6d7U>
.
|
|
Sure, but the CMake-based build system will have to be updated whenever the
Makefile-based does. @giaf has no interest in doing so and the same might
hold for any other dependency. We can definitely move everything to CMake,
but we should keep in mind that it will add a step in the integration
process of external software packages.
On Apr 21, 2017 6:43 PM, "Robin Verschueren" <notifications@github.com>
wrote:
Why would you want them to be in sync? With acados, we use the Makefile
generated by CMake, if you have hpmpc and/or blasfeo standalone you can
choose between this or the Makefile handwritten by @giaf.
On Fri, 21 Apr 2017 at 07:26 zanellia ***@***.***> wrote:
So, although I do like the idea of having all the external projects using
CMake, as Gianluca pointed out, it might be difficult to keep Make- and
CMake-based build systems in sync. This holds for hpmpc and blasfeo and it
is even more of a relevant issue with other dependencies like qpOASES.
Thoughts?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#61 (comment)>, or
mute
ABXrjEvBwCr4IdqW6fVyLbtYIvS3Lr8mks5ryLyngaJpZM4M6d7U>
.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#61 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AQCkff_AkIOPka7IlpD2ZPBgeq2RBw4Eks5ryNyVgaJpZM4M6d7U>
.
|
|
Hi all, since both @giaf and @roversch asked for CMake for hpmpc and blasfeo, you can find the link to my (very rough) version of the build system for hpmpc here: https://github.com/zanellia/hpmpc/blob/crosscompiling/CMakeLists.txt Analogously the one for blasfeo is here: https://github.com/zanellia/blasfeo/blob/crosscompiling/CMakeLists.txt They only work for a single target since I only needed that specific version when hacked CMake in. However, it should be very easy to extend to all the other targets. |
|
Yep I already found ;) And I added cmake to HPIPM (that by the way now is only missing partial condensing, compared to HPMPC) |
|
Awesome! Does it have partial tightening too? That was QUICK.
2017-06-17 17:35 GMT+02:00 giaf <notifications@github.com>:
… Yep I already found ;)
And I added cmake to HPIPM (that by the way now is only missing partial
condensing, compared to HPMPC)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#61 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AQCkfarES0-N9FXs4v2PBa1U4hGg2oZcks5sE_IlgaJpZM4M6d7U>
.
|
|
nope there is no partial tightening, that will be your part of the fun ;) |
|
it has ipm for dense qp, ipm for ocp qp, (full) condensing from ocp qp to dense qp |
|
@roversch HPMPC won't get any cmake: as soon as HPIPM is up and running, we can remove HPMPC from ACADOS |
|
@giaf it might be good to have stable version of hpmpc to be used in acados
before we move to hpipm, what do you think?
…On Jun 18, 2017 19:11, "giaf" ***@***.***> wrote:
@roversch <https://github.com/roversch> HPMPC won't get any cmake: as
soon as HPIPM is up and running, we can remove HPMPC from ACADOS
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#61 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AQCkfeEQQtzn3Rg0GSirGqznMKSvxkJuks5sFVo8gaJpZM4M6d7U>
.
|
|
the "stable version of HPMPC" is the one already used in ACADOS, and I'm not putting any more effort in improving it and HPIPM is stable and ready to be used, you can give it a try ;) |
|
@zanellia how did you choose cmake minimum version 2.8.11 in your cmake (that I just copied for now, but I would like to know more about?) |
|
I just copied that from acados? I do not remember to be honest.
2017-06-19 11:25 GMT+02:00 giaf <notifications@github.com>:
… @zanellia <https://github.com/zanellia> how did you choose cmake minimum
version 2.8.11 in your cmake (that I just copied for now, but I would like
to know more about?)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#61 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AQCkfcpCVIQ-Dko9sfAMsGIey5qbVBuOks5sFj6bgaJpZM4M6d7U>
.
|
|
In my pc I have version 3.5. What is the oldest version you tested on? Also, I had to replace all EQUAL with MATCHES in order to make it work properly |
|
I downloaded 2.8.0 and it fails with BLASFEO due to the assembly code. |
|
Closing this in favour of #57 |
I had some troubles managing ExternalProjects based on Makefiles so I made a minimal port of hpmpc's build system to CMake. Not sure this is better than a Makefile-based build system, but at least all our core code is going to be built with CMake (good? dunno). Anyways, if you guys like it we could give it a shot. The code is here:
https://github.com/zanellia/hpmpc/tree/crosscompiling
and it is based on a single CMakeLists.txt file (unlike the previous hpmpc's CMake build system).
The text was updated successfully, but these errors were encountered: