build: add cmake support

[gocarlos]

No description provided.

[lategoodbye]

Could you please explain why conan support is necessary?
Also why all these changes to the sources?

[gocarlos]

Could you please explain why conan support is necessary?
Also why all these changes to the sources?

• conan support is here to allow others to consume this library with a language package manager.
• only change to the sources were moving bin to example (people tend today imho to expect a include, test, src and example folder) and eventually some automatic formatting (this repo does not have any style formatter ala clang-format)
  the move to example can be reverted of course

furthermore I'll add a C++ RAII wrapper in the folder contrib, this is optional e.g. default off at compile time, this MR is WIP

[gocarlos]

lets add conan and wrapper in a next MR

[lategoodbye]

* conan support is here to allow others to consume this library with a language package manager.

I like to have this a separate commit.

* only change to the sources were moving `bin` to `example` (people tend today imho to expect a `include`, `test`, `src` and `example` folder) and eventually some automatic formatting (this repo does not have any style formatter ala clang-format)
  the move to `example` can be reverted of course

I'm not against this change, i only wanted to know why. The initial idea was a library, but from my understanding most of the user doesn't use the library to build an own application. They only use the example binaries.

[gocarlos]

* conan support is here to allow others to consume this library with a language package manager.

I like to have this a separate commit.

* only change to the sources were moving `bin` to `example` (people tend today imho to expect a `include`, `test`, `src` and `example` folder) and eventually some automatic formatting (this repo does not have any style formatter ala clang-format)
  the move to `example` can be reverted of course

I'm not against this change, i only wanted to know why. The initial idea was a library, but from my understanding most of the user doesn't use the library to build an own application. They only use the example binaries.

• I’ll add this lib directly to conan center as soon as cmake is merged (github release would be great after the merge as those package managers tend to use git tags)
• ok i did not know that people only use the binaries, we just use them as a how to, e.g. example and link this lib to our existing binaries...

I’ll rebase and change the patch/commit message accordingly

[Apollon77]

@lategoodbye

The initial idea was a library, but from my understanding most of the user doesn't use the library to build an own application. They only use the example binaries.

Are you really sure? Yes for end-users this might be true. But your library is included as lib in many projects! Not only my nodejs library is based on it, also volkzaehler project and others ... soI think it is more often used as library then as binaries ... ;-)

[lategoodbye]

@lategoodbye

The initial idea was a library, but from my understanding most of the user doesn't use the library to build an own application. They only use the example binaries.

Are you really sure? Yes for end-users this might be true. But your library is included as lib in many projects! Not only my nodejs library is based on it, also volkzaehler project and others ... soI think it is more often used as library then as binaries ... ;-)

My statement based on the Github issues, since i don't have statistics about the libmbus usage. Maybe you have a better overview about the usage. I only want to say that the "example" binaries are an important part of this project.

[gocarlos]

I only want to say that the "example" binaries are an important part of this project.

I would rename bin to examples as I think those are examples...

but this can potential be done in a next MR, @lategoodbye is here anything else you need to have to get this merged?

[lategoodbye]

I only want to say that the "example" binaries are an important part of this project.

I would rename bin to examples as I think those are examples...

And that's fine.

[lategoodbye]

Since you introduce cmake, please try to take care of the other stuff like deb / RPM spec. Sorry, i'm not that cmake expert but it would be great to make maintaining easier.

Btw i suggest to use the github URL instead of the rscada because we have the newer releases.

[gocarlos]

Since you introduce cmake, please try to take care of the other stuff like deb / RPM spec. Sorry, i'm not that cmake expert but it would be great to make maintaining easier.

Btw i suggest to use the github URL instead of the rscada because we have the newer releases.

this should pretty straight forward, can take on that....
though I think that if we are going this path (my goal was originally to just add a simple cmake build script to make integration with conan/cmake easy), then it does not make sense to keep the other build system e.g. we should then also remove it in the future

[lategoodbye]

In the long run, i don't want to maintain two build systems (except of Windows). So i appreciate a proper cut, if it's possible.

[Apollon77]

I hope I get my windows fork working with all these changes ;-) might be a challenge ... we will see

[gocarlos]

I hope I get my windows fork working with all these changes ;-) might be a challenge ... we will see

almost nothing changed -> added cmake scripts and config.h which is then configured by cmake...
your fork is mostly doing changes to the source code itself e.g. serial abstraction layer ?

[Apollon77]

@gocarlos basically as in https://github.com/rscada/libmbus/pull/133/files ;-)

[Apollon77]

I don't found time till now to adjust to @lategoodbye 's wishes to get progress

[gocarlos]

@lategoodbye could you review again? the docker images are here to create the rpm and deb files one is using another system e.g. mac or windows

[gocarlos]

I think i've found another issue. If i run ./build the test binaries are build, but not copied into the test directory. This is necessary for the generate-xml.sh script.

actually I changed the generate-xml.sh in the next MR to take in the location of the binaries... copying the binaries into the source tree is a bad practice. All artifacts should be in the build directory

[gocarlos]

already 63 comments for a simple cmake script 🥇 👯 😄

[madebr]

already 63 comments for a simple cmake script 🥇 👯 😄

Let's stop at 69 :3 😄

[gocarlos]

I think i've found another issue. If i run ./build the test binaries are build, but not copied into the test directory. This is necessary for the generate-xml.sh script.

actually I changed the generate-xml.sh in the next MR to take in the location of the binaries... copying the binaries into the source tree is a bad practice. All artifacts should be in the build directory

done

[gocarlos]

@lategoodbye still something missing?

[lategoodbye]

I think i've found another issue. If i run ./build the test binaries are build, but not copied into the test directory. This is necessary for the generate-xml.sh script.

actually I changed the generate-xml.sh in the next MR to take in the location of the binaries... copying the binaries into the source tree is a bad practice. All artifacts should be in the build directory

done

Sorry, i didn't noticed that you are finished with the pull request.

I really hate scripts which are impractical. Could you please make the second parameter optional and use ./_build/bin/mbus_parse_hex as default? This would make it behave as before.

[gocarlos]

I think i've found another issue. If i run ./build the test binaries are build, but not copied into the test directory. This is necessary for the generate-xml.sh script.

actually I changed the generate-xml.sh in the next MR to take in the location of the binaries... copying the binaries into the source tree is a bad practice. All artifacts should be in the build directory

done

Sorry, i didn't noticed that you are finished with the pull request.

I really hate scripts which are impractical. Could you please make the second parameter optional and use ./_build/bin/mbus_parse_hex as default? This would make it behave as before.

done

[lategoodbye]

Thanks

[lategoodbye]

@gocarlos @madebr

Unfortunately i found another issue. Now the libmbus is installed under the wrong name: liblibmbus.so if i call make install from the build directory.

Sorry, for not noticing this before. Can anyone of you give me an hint or send a pull request to fix this?

Thanks

[gocarlos]

Add_library in cmake is using the name libmbus, as linux uses lib prefix it produces liblibmbus

set_target_properties(${PROJECT_NAME} PROPERTIES PREFIX "")

[lategoodbye]

Thanks again. I pushed 1e25cf1

[lategoodbye]

@gocarlos In #174 i noticed that some build artifacts like libmbus.a libmbus.la are now missing. Is it possible to fix this?