Package Details: copperspice 1.9.1-1

Git Clone URL: (read-only, click to copy)
Package Base: copperspice
Description: Libraries for developing cross platform software applications in C++
Upstream URL:
Keywords: Qt
Licenses: LGPL-2.1-only
Submitter: dbermond
Maintainer: dbermond
Last Packager: dbermond
Votes: 3
Popularity: 0.000095
First Submitted: 2021-01-06 00:49 (UTC)
Last Updated: 2024-03-06 22:18 (UTC)

Latest Comments

1 2 Next › Last »

dbermond commented on 2023-02-25 16:39 (UTC)

@seasoned_geek I saw that one, thank you. But I do not have access to the paid area.

seasoned_geek commented on 2023-02-25 16:38 (UTC)

I guess most of them would be in the paid support area. There is this one which is when I was looking for method to contact you.

dbermond commented on 2023-02-25 15:36 (UTC)

@seasoned_geek Not sure if this is the case of your doubt, but the '-none.cmake' suffix is because this package uses the cmake none build type. Other cmake build types will give different suffixes.

Could you please point out some links with the complaints about this package? I could not find them on the copperspice forum.

seasoned_geek commented on 2023-02-25 14:17 (UTC)




Those files are not created/generated on any other target.

I have built CopperSpice on many platforms. The -none.cmake files only get generated with the AUR build.

Oh well, thanks for replying. Now I see why there are complaints in the CopperSpice forum about this particular build. Thanks again for replying.

dbermond commented on 2023-02-25 13:56 (UTC)

@seasoned_geek If you're talking about the developer perspective, then your are searching for cmake documentation about exporting targets. But I doubt that this is what you need, because you said that your purpose is to create a Debian package, and a packager is not supposed to mess with it (unless upstream does not export their cmake targes, which is not the case in copperspice).

I do not "somehow" created the .cmake files, that's what I'm trying to tell you all the time. The upstream building process creates them automatically, and no manual packager intervention is needed for creating them. These files are the exported cmake targets, that are used for importing the copperspice targets for end users. Upstream coded it in their source code, and the cmake build process builds and installs them on the package when invoking cmake.

Regarding plugins, they are being installed in the default path specified by upstream. I've not changed the plugin install path on the package. For example, if you take a look at the cups printer driver plugin, it's being installed in CMAKE_INSTALL_LIBDIR, as specified in upstream source code. So, end users should not have problems loading it. If you have a problem loading plugins from this package, I think you should report it upstream, as they are on the default upstream path.

I've tried to help you as much as I can, but creating a Debian package is out of the scope of the AUR. I gently ask you to seek such help in the proper Debian support channels.

seasoned_geek commented on 2023-02-22 16:01 (UTC)

I really hate that auto-format. Here's a link to an image of the directory tree.

seasoned_geek commented on 2023-02-22 15:59 (UTC)


Yes, how to create them from a developer perspective. You somehow created or caused them to be created with this AUR bundling. When you pull down the CopperSpice source from the official repo on Ubuntu, Fedora, or other Linux platform, those files do not exist.

You have a bug too. It's all well and good to place the libraries in /usr/lib, but you must copy those files needed for plugins to the tree. developer@developer-U18-Dev-VirtualBox:/$ cd /usr/lib developer@developer-U18-Dev-VirtualBox:/usr/lib$ tree copperspice copperspice ├── bin │   ├── lconvert │   ├── linguist │   ├── lrelease │   ├── lupdate │   ├── rcc │   └── uic └── plugins ├── iconengines ├── imageformats │   └── ├── mediaservices │   ├── │   ├── │   └── ├── pictureformats ├── platforms │   ├── │   └── ├── playlistformats │   └── ├── printerdrivers │   └── ├── sqldrivers │   └── └── xcbglintegrations └──

11 directories, 16 files developer@developer-U18-Dev-VirtualBox:/usr/lib$

CopperSpice has hard coded logic looking for plug-ins under their proper directories. Even using addLibrary("/usr/lib") in main.cpp prior to creating the app class won't make CopperSpice find the plugins. If the files are in the official tree addLibrary("/usr/lib/copperspice/plugins") in main before creation of app will allow all programs to find them.

dbermond commented on 2023-02-04 17:17 (UTC)

@seasoned_geek Yes I really cannot understand what do you mean, and looks like I still could not understand either. By "how to create them", do you mean "how to create them" on your Debian package? If so, the answer is the one that I gave: no intervention needed (you do need to do anything for they to be created), as the build system automatically creates them when you invoke cmake/make/make install, and they will be right there at your install path. Or do you mean how to create them from a developer perspective (like by writing cmake files/sources)?

seasoned_geek commented on 2023-02-02 10:47 (UTC)

@dbermond You misread/misunderstood my question. I was asking "how to create them" not if I had to manually do it. I was working on some packaging for Debian and wanted to follow the same path. In the end I abandoned the CMake hijinks for a more tried and true shell script.

I did keep much of the same directory tree structure. Should be releasing by end of weekend.

dbermond commented on 2023-01-21 16:06 (UTC)

@seasoned_geek They are automatically generated by the upstream build process. No manual intervention needed for creating them.