Conversation
0720ea6 to
e08ef2e
Compare
|
The two bugfix commits look fine to me (and thanks for fixing the linker error - I just saw the issue that points that out in the code I wrote a while ago). I am not convinced that the CPack parts of the CMake are a good idea though. What is wrong with doing a make install and using a separate deb creation script? Every use of the CPack I have seen has always been debian specific it seems, which is not going to be universal (I personally use RPMs on Fedora). |
|
The CPack is definitely something which is not widely popular. Personally, I use both the NSiS (windows), .deb and .rpm archives fairly regularly, with just the 'package' target. For me, the main benefit is having a clean uninstall of whatever test version I want to try out It's of course your project, so feel free to pick only the other fixes. |
|
First of all, thanks for the PR and the bug fixes. Regarding CPack, I would also be in favor of keeping the cmake as general as possible. |
|
As far as I know, there's no uninstall in cmake. For me personally, having it as package means the system package manager can always uninstall it, even if the source archive changes/is removed. Would it be better if I strip out the debian specific lines (that's 1168 to 1177) ? |
I think this sounds as a good compromise. Is there a specific reason for choosing |
It is fairly easy to add an uninstall target to CMake, and it actually exists in the Acados CMake so I could port it to the BLASFEO CMake with little trouble. |
If it makes the job for everyone, this would be my preferred solution too. |
This defines a cmake package, such that 'make package' will create an package or installer which can be removed from the system.
It also fixes a linker error (multiple definitions of BLASFEO_PROCESSOR_FEATURES)