[KEXI] [Bug 369232] cmake fails on missing rcc, it's a runtime dep though

2019-05-03 Thread Jarosław Staniek
https://bugs.kde.org/show_bug.cgi?id=369232

--- Comment #4 from Jarosław Staniek  ---
In addition, breeze-icons.rcc will be used for app-wide autotests, when the
main GUI is invoked. For now we have one autotest like this. I rather consider
running autotests and ensuring they pass as a prerequisite of packaging, or a
post-build step. Therefore, configure-time check for presence of
breeze-icons.rcc is not a bad thing.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kexi] [Bug 369232] cmake fails on missing rcc, it's a runtime dep though

2017-01-10 Thread Rex Dieter
https://bugs.kde.org/show_bug.cgi?id=369232

Rex Dieter  changed:

   What|Removed |Added

 CC||rdie...@math.unl.edu

-- 
You are receiving this mail because:
You are watching all bug changes.

[kexi] [Bug 369232] cmake fails on missing rcc, it's a runtime dep though

2016-09-24 Thread Jarosław Staniek via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=369232

--- Comment #3 from Jarosław Staniek  ---
"I cannot think of a single packaging environment where build environment ==
run environment."

This is stronger requirement Kexi does not have. No need to use this argument.

"The rcc being there at buildtime doesn't mean anything WRT runtime."

Yes but only in worst case, when the intent of person compiling is rather
wrong. Based on what I know packagers (with intent to ship properly) are rather
grateful for pointers they get from the configure time. And people that build
Kexi for the first time in order to start contributing. 
On top of that Kexi properly communicates what's required and recommended
dependency at configure time, that's the case since the older times of KOffice
and Calligra.

Thanks for double checking this.

Also I think we would change the subject "cmake fails on missing rcc" because
it's failure in doing something, not overlook, it's a programmed behaviour with
clear messages in English.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kexi] [Bug 369232] cmake fails on missing rcc, it's a runtime dep though

2016-09-23 Thread Harald Sitter via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=369232

--- Comment #2 from Harald Sitter  ---
I have to confess I am going a bit TLDR on the response but I think the key
problem is that previously before cmake RUNTIME we didn't have a way to
communicate runtime deps in a *standardized* way. Which means packagers had no
chance to deal with them efficiently. They now do, exactly the way as we do
with other dependencies. If they don't make use of that, then they are just
being bad at their job.

find_package could even be made required and skipped with
CMAKE_DISABLE_FIND_PACKAGE_$NAME  by the packagers. So you get the same end
result but you do it in a standard fashion.

Regardless of any of this. I cannot think of a single packaging environment
where build environment == run environment. The rcc being there at buildtime
doesn't mean anything WRT runtime.
On deb/rpm the rcc would need to be a runtime dep. In snap/flatpak/appimage the
rcc needs to end up in the bundle (which fortunately is the default), same on
other platforms.

You need to assert it as runtime dependency in a standard fashion, everything
else is just wishful thinking.

-- 
You are receiving this mail because:
You are watching all bug changes.


[kexi] [Bug 369232] cmake fails on missing rcc, it's a runtime dep though

2016-09-23 Thread Jarosław Staniek via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=369232

Jarosław Staniek  changed:

   What|Removed |Added

 CC||stan...@kde.org

--- Comment #1 from Jarosław Staniek  ---
I understand the desire for purity. But we had to choose something closer to
good deployment practices and implemented without stressing the packagers
though so the packagers are able to deliver *working* packages. The problem is:
Kexi is being packaged without the .rcc file as a runtime dependency leads to
deployment failure. Then users are confused that Kexi refuses to start. 

It's hard to accept this approach in practice so I came up with the behaviour
as you explained. openSUSE package maintainer who collaborated with me on these
improvements was able to properly package the app and libs.

In the years of history it just happens that some packagers never actually run
the app, I don't even dream about them always running autotests (before
shipping). But in a pro world this is one of items on the check list.

If we have a way to ensure packager sets proper runtime dependencies, I'd
happily change the FATAL_ERROR to just a warning. For now warnings are pretty
much ignored by those deploying the software, and of course I am not surprised.

Requiring runtime dependencies at packaging time isn't something unusual if you
assume that before finalizing the process of building Kexi running autotests is
required (but still this cannot be forced because e.g. build systems lack
$DISPLAY). When tests are executed, the icons have to be accessible (and all
other runtime dependencies for that matter). This is why I am thinking there's
not much to fight for.

Those, in rare cases, who want to take responsibility of disabling the check
can patch the cmake script and then ensure ("by hand") that the runtime
requirements are in proper version. But let's realize that for example in the
KDb project in the future as we move on with features we would be checking
exact features of dependencies such as SQLite in exactly the same way: by
requiring the runtime deps at configure time. Some cmake's Find*.cmake actually
check the software by building and running apps at configure stage to really
know what features we have. So that's not a new thing.

Disclaimer: packagers are doing great work but just don't have the resources to
study internal of requirements in given software. App maintainer on the other
hand cannot accept software installation that are not working because of so
simple reason/mistake as described.

PS: it would be best if the check was exported as a cmake script in
breeze-icons.git.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kexi] [Bug 369232] cmake fails on missing rcc, it's a runtime dep though

2016-09-23 Thread Jarosław Staniek via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=369232

Jarosław Staniek  changed:

   What|Removed |Added

 OS|Linux   |All
Version|unspecified |3.0 Beta

-- 
You are receiving this mail because:
You are watching all bug changes.