New Pentax Driver #66
Conversation
… devices existed.
…licts between the standard version of libmtp and the custom version of libmtp used by the Ricoh SDK.
… changing modes. Minor bug fixes.
There was a problem hiding this comment.
Does libpktriggercord needs to be included in 3rd-party? Is it available else where? I see https://github.com/asalamon74/pktriggercord/ is it possible to configure the CMake to build the library there?
The reason I ask for this is two folds:
- It would cut down on any unnecessary libraries in indi-3rdparty repo.
- More importantly, if we use the source the two versions would not start diverging and we need to manually patch this library to sync it with the upstream one.
So if there is a way to configure the upstream to produce the necessary shared library you need, then we can create a debian package for it.
libpktriggercord/CMakeLists.txt
Outdated
|
|
||
| set (PK_VERSION 0.85.01) | ||
| set (PK_SOVERSION 0) | ||
| set (PK_DATADIR /usr/local/share/pktriggercord) |
There was a problem hiding this comment.
is there a reason this is /usr/local vs /usr ? For system-wide installation, we would opt for /usr/share/pktriggercord
There was a problem hiding this comment.
libpktriggercord is a shared library wrapper I made for pktriggercord, since pktriggercord just provides an executable. I have no idea if the author / maintainer would be open to making the necessary changes and supporting a library version, or not. I suppose I could fork it myself and take responsibility for keeping things in sync. One complication is pktriggercord doesn't use cmake.
/usr/local was just the default in the makefile for pktriggercord. I don't think there's any reason it needs to stay this way.
There was a problem hiding this comment.
There was a problem hiding this comment.
I had gotten started on this in a fork. I remember having to break out some functions from certain source files into a separate file, and of course updating the makefile. I think I ran into a hiccup somewhere and stopped. It looks like I never pushed my changes. Hopefully I can find the system image I was working on when I was doing that, and send a pull request.
There was a problem hiding this comment.
I would be really interested to see this as well. I started the same work a few months ago before moving on to something else. I've got a working library without breaking any function (as I know of).
But I'm not a skilled C++ programmer, and absolutely not familiar with library development. The way I've got it to work was to simply expose all functions inside pslr.c. See this fork
pktriggercord deserves to have its own library, rather than having a fork per software that supports pentax cameras as it is today.
There was a problem hiding this comment.
I exposed some of the cli functions as well as the pslr.c functions, which meant rearranging the code somewhat. I'm not a skilled programmer myself, but I think what I did is clearly a hack rather than a long-term solution, and the code needs some refactoring to get to the point where it's library-friendly. Anyway, my work's in this pull request: asalamon74/pktriggercord#48. Maybe Andras can create a branch for it. We should probably continue the discussion over there.
|
So if the upstream project is feature-complete and stable with very few changes. Forking it (or including a stripped-down version in indi-3rdparty) would be a good option. If it is expected to receive a lot of updates, then it's better to ask the author about making a library version (maybe via a CMake switch). |
|
The upstream project hasn't changed much in the last few years, but it's possible it would receive significant updates from time to time. I forked pktriggercord and updated it to support making a library. I then added a lib target to produce a .so file. I'm going to submit a pull request to the author, but before I do, I want to make sure that I'm producing everything I need to produce, and I'm not quite clear what it is you're proposing. Are you suggesting I just copy to .so file and .h files into indi-3rdparty so indi-3rdparty can install them, or try to get the author to install the lib file in a separate debian package? Do I need to produce anything else? |
|
One option would be to strip down the forked pktriggercord version and then we can include it in indi-3rdparty. There is a lot of unnecessary stuff in there (Android..etc) that is not needed. So we still need the source, just a more stripped down version (if it is to be included in indi-3rdparty). Otherwise, you can keep your own form of pktriggercoord as is, and it will be added as an external dependency (i.e. not included in indi-3rdparty). |
|
I removed all unnecessary files from the libpktriggercord folder. Will that do? |
|
Excellent! This is looking good. The final thing is to have the debian files for indi-pentax, and the other two libs. Just look inside the debian directory and use whatever there as your template, it should be fairly easy to do so. I think that's pretty much it at this stage. |
|
@karlrees Any update on the debian files? Do you need help in those? |
|
Ok, it's merged and looking good, but the Ricoh library is getting linked to the system MTP library and not the one you're building. Also, I presume this is all designed for Linux? it won't work on Mac? |
|
Sorry, got a bit busy. I just committed debian files to my fork. I really don't know much about them or how to test them. Guess I should submit a new pull request for them. One question though--do I need the .install files. Seemed like the docs were saying those are only needed for files/actions that aren't being installed by the makefile? This is all designed for Linux. I assume someone could probably get it working on a Mac, but I don't have a way to test it out right now. I thought I'd fixed the linking problem by using rpath. Guess I'll have to take a closer look again. |
|
.install are not strictly required unless you have different packages from one source. If one package, then not required. Yes, please create a PR and send them. I will of course test and and fix any issues accordingly. Great work Karl, this is going to make a lot of users happy! |
Added a new Pentax driver and associated libraries. See indi-pentax README for details.
Right now, I've named the driver indi_pentax. I would have used indi_pentax_ccd, but that's taken by the redirect to the gphoto driver. I'm open to alternatives. I think perhaps the redirect to the gphoto driver should be removed in the long run, as I believe this driver is superior in every aspect, but of course some testing is needed first.
I have no idea how to do the debian packaging stuff. I looked at a few references, and it made my head dizzy. I'm hoping for some help on that.