search

seandepagnier / rtlsdr_pi

rtlsdr plugin for opencpn for AIS vhf and more on tv tuner usb dongle
30 stars 14 forks source link

Fixing in tree build #5

Closed dominig closed 9 years ago

dominig commented 9 years ago

Hello, could you please consider that small correction which enable in tree building of your plug in. Due to the way OpenCPN is built for OpenSUSE, I need that done and I would rather have it upstream rather than to maintain a patch on the build system.

Regards

Dominig

seandepagnier commented 9 years ago

Sure, I don't mind as long as it doesn't break out of tree.

Could you explain why you need to build in-tree for suse? This will help me better understand the situation to better avoid future problems.

On Fri, Jan 30, 2015 at 10:58 AM, Dominig ar Foll notifications@github.com wrote:

Hello, could you please consider that small correction which enable in tree building of your plug in. Due to the way OpenCPN is built for OpenSUSE, I need that done and I would rather have it upstream rather than to maintain a patch on the build system.

Regards

Dominig

You can view, comment on, or merge this pull request online at:

https://github.com/seandepagnier/rtlsdr_pi/pull/5 Commit Summary

  • Fixing in tree build

File Changes

Patch Links:

— Reply to this email directly or view it on GitHub https://github.com/seandepagnier/rtlsdr_pi/pull/5.

dominig commented 9 years ago

Hello,

I doubt that what I have done will break your normal building mode, but obviously, it is something that you want to check.

Why in tree build.

I maintain OpenCPN on OpenSUSE and this is built over a cloud based system called OBS. I allows me to build for several version of OpenSUSE while offering a one click install. OBS take a git tree or a tar ball with a set of patches and run the building process of it in an isolated chroot.

The building in tree technique allows me to provide a single package which includes all the plugin that I know will work. I does provide three major advantages :

My goal is to deliver a full working OpenCPN from a one click install (I am publishing in the official application domain). It works for 3.x and I want to offer the same with 4.x.

Regards

2015-01-30 11:17 GMT+01:00 seandepagnier notifications@github.com:

Sure, I don't mind as long as it doesn't break out of tree.

Could you explain why you need to build in-tree for suse? This will help me better understand the situation to better avoid future problems.

On Fri, Jan 30, 2015 at 10:58 AM, Dominig ar Foll < notifications@github.com> wrote:

Hello, could you please consider that small correction which enable in tree building of your plug in. Due to the way OpenCPN is built for OpenSUSE, I need that done and I would rather have it upstream rather than to maintain a patch on the build system.

Regards

Dominig

You can view, comment on, or merge this pull request online at:

https://github.com/seandepagnier/rtlsdr_pi/pull/5 Commit Summary

  • Fixing in tree build

File Changes

Patch Links:

— Reply to this email directly or view it on GitHub https://github.com/seandepagnier/rtlsdr_pi/pull/5.

— Reply to this email directly or view it on GitHub https://github.com/seandepagnier/rtlsdr_pi/pull/5#issuecomment-72180439.

Dominig ar Foll Senior Software Architect Intel Open Source Technology Centre

nohal commented 9 years ago

@seandepagnier There is no problem with it. It is exactly the same stuff as we already did elsewhere. As I already explained you, out of the tree CMAKE_SOURCE_DIR == PROJECT_SOURCE_DIR. Not so when you build inside the OpenCPN main tree - in that case CMAKE_SOURCE_DIR points to opencpn's src directory while PROJECT_SOURCE_DIR points to plugin's src directory. The problem is obvious - using CMAKE_SOURCE_DIR causes the plugin to mess up with main application files (like overwriting version.h, for example). Changing all the occurrences of CMAKE_SOURCE_DIR with PROJECT_SOURCE_DIR in the plugin's cmake files is the way to go and causes no problems.

@dominig Doesn't OBS support package dependencies? Is there a reason not to have separate RPMs for the plugins as we do on Launchpad and in the fedora repository? It seems to be a bit of an overkill to have to reinstall the whole package when a single plugin gets updated... Yes, there is a few basically unmaintained plugins that do not build out of the tree, but it would be better to fork and fix those IMO...

P.

dominig commented 9 years ago

2015-01-30 19:01 GMT+01:00 Pavel Kalian notifications@github.com:

@dominig https://github.com/dominig Doesn't OBS support package dependencies? Is there a reason not to have separate RPMs for the plugins as we do on Launchpad and in the fedora repository? It seems to be a bit of an overkill to have to reinstall the whole package when a single plugin gets updated... Yes, there is a few basically unmaintained plugins that do not build out of the tree, but it would be better to fork and fix those IMO...

Yes OBS can manage dependencies but maintaining them with each version of plugins is a bit of a pain. Providing a single package is certainly using brute force, but as I do not address developers but rather simple user, they so far quite like the concept. No question asked you just get the all lot in one go :-)

Dominig ar Foll Senior Software Architect Intel Open Source Technology Centre

seandepagnier commented 9 years ago

@dominig It's up to you what you want to do, but I think it's a bit ridiculous to download a huge package which contains all the data for all the plugins. Further, the main application should be broken into several packages like it is on debian, so an upgrade can only download a few files, not the world coastline data, or documentation which updates infrequently.

Maybe you don't care about data transfer speed, but I currently in a big city and very lucky to have 20kb/s internet and often it's much slower than that.

On Sat, Jan 31, 2015 at 3:34 AM, Dominig ar Foll notifications@github.com wrote:

2015-01-30 19:01 GMT+01:00 Pavel Kalian notifications@github.com:

@dominig https://github.com/dominig Doesn't OBS support package dependencies? Is there a reason not to have separate RPMs for the plugins as we do on Launchpad and in the fedora repository? It seems to be a bit of an overkill to have to reinstall the whole package when a single plugin gets updated... Yes, there is a few basically unmaintained plugins that do not build out of the tree, but it would be better to fork and fix those IMO...

Yes OBS can manage dependencies but maintaining them with each version of plugins is a bit of a pain. Providing a single package is certainly using brute force, but as I do not address developers but rather simple user, they so far quite like the concept. No question asked you just get the all lot in one go :-)

Dominig ar Foll Senior Software Architect Intel Open Source Technology Centre

— Reply to this email directly or view it on GitHub https://github.com/seandepagnier/rtlsdr_pi/pull/5#issuecomment-72257147.