Skip to content
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

cross-compiling kinetic-cpp-client #35

Open
kinjalcpatel opened this issue Sep 16, 2015 · 7 comments
Open

cross-compiling kinetic-cpp-client #35

kinjalcpatel opened this issue Sep 16, 2015 · 7 comments

Comments

@kinjalcpatel
Copy link

Hi,

Are you working on cross-compilation of kinetic-cpp-client?

@plensing
Copy link
Contributor

Hello,
I am sorry you did not get a response (much) sooner. Cross compilation for the kinetic-cpp-client is not being worked on at the moment as far as I know. Do you still have a need for this feature? And if so, cross compiling from where to where?

@kinjalcpatel
Copy link
Author

kinjalcpatel commented Sep 26, 2016

Hi,

It was required while We were working on the Kinetic based product. I am no longer working on the product now.
But i did worked on cross compilation for kinetic-cpp-client that time. I had added my changes to My working branch
@pkufeldt please chime in if you like to add some details.
We wanted to make the compilation generic which can support various platfoms(x86, arm, etc). I have removed the cmake based build support and added autotools build support.

If you like to merge it, i can create pull request, but i am no longer actively working in this project now.

@pkufeldt
Copy link

It is important that the libraries/clients build be cross compile-able. Furthermore the clients should not have dependent libraries checked in with them but rather should have a build that defines the correct library dependencies. Toshiba embarked on this work and I thought it was fully checked into the CPP libraries and was pending on the C Libraries. @kinjalcpatel didn't this get done?

@plensing
Copy link
Contributor

plensing commented Sep 27, 2016

The cmake build system has just been rewritten and now offers a lot of modularity (such as giving the user a choice of linking dynamically against installed library dependencies or building and linking packaged dependencies / versions provided by the user statically).

There is, however, no cross compilation support as of now.

@pkufeldt
Copy link

pkufeldt commented Sep 27, 2016

The existing cmake build is not sufficient for those building embedded appliances. Many times you will be cross compiling for ARM or some other non-intel environment. The library/app builds will be embedded in a linux distro build like Yocto, Open Embedded or buildroot and should look and behave like other open source library/app builds. While there are other cmake built libraries/apps out there the most common method of building is autotools/configure. All of the linux distro builds support configure builds and configure builds support cross compiling. Furthermore a properly defined configure build removes the need for any dependencies checked into the library/client build as it is with the current cmake build. Both Toshiba's drives and HGST drives need cross compiling. Plus any new embedded Kinetic devices that might not even be a disk form factor but are non-intel could leverage this. @kinjalcpatel can you comment further on the the status of the autotools build

@plensing
Copy link
Contributor

plensing commented Oct 5, 2016

There is no need for checked in dependencies with the current build system either. It is purely a convenience for people wanting to try out the client without having to install dependencies.

And while there is no cross compiling support in addition to standard cmake cross compiling... have you tried that and encountered problems?

Assuming you have all dependencies already cross compiled, it should work the standard way by supplying a toolchain file.

@pkufeldt
Copy link

pkufeldt commented Oct 6, 2016

Yes we tried. And furthermore it didn't fit into the existing distro build environments. This should be made to look like any of the other open source libraries, mirroring their builds. This makes it easier for new developers to come into the fold and start using these libraries as it will match their past experiences. Plus it will match automation systems that have been building std linux libraries for years. Putting dependencies in the tree is not the std way of building libraries and just increase download and build time. When automating distro builds rebuilding libraries N times because they occur in N packages makes difficult/lengthy task even harder/longer.

Again we completed this work it is was supposed to be checked in. @kinjalcpatel wasn't this completed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants