mplayerthumbsconfig ( small gui to set mplayer path) is supposed to build with videopreview as a module/plugin (videopreview.so) but couldn't manage to build It that way, therefore I build videopreview both as a module and a static library, then mplayerthumbsconfig is linked with the static lib.
videopreview.so is still provided as a module for other apps to use (which one?).
There is no po files at the moment.
Strips over thumbnails is enabled by default with automake, since we usually build with all options, I've set It up with ${WITH_ALL_OPTIONS}, Slavek, if you prefer that option set "on" or "off" by default, just tell me, I'll change It.
mplayerthumbsconfig ( small gui to set mplayer path) is supposed to build with videopreview as a module/plugin (videopreview.so) but couldn't manage to build It that way, therefore I build videopreview both as a module and a static library, then mplayerthumbsconfig is linked with the static lib.
videopreview.so is still provided as a module for other apps to use (which one?).
There is no po files at the moment.
Strips over thumbnails is enabled by default with automake, since we usually build with all options, I've set It up with ${WITH_ALL_OPTIONS}, Slavek, if you prefer that option set "on" or "off" by default, just tell me, I'll change It.
Because there were more changes, I made an amend to your commit instead of review:
The entire part with the add_custom_command and set_source_files_properties for mplayerthumbs.kcfgc was ineffective. Since mplayerthumbs.kcfgc is not a source file for object compilation (such as cpp=>o), set_source_files_properties has no effect on such a file and therefore custom command has never been executed.
Since mplayerthumbs.kcfgc was listed as the source for two libraries, it was actually processed 2×. If the previous custom command would work, it would be processed 3×.
Linking the module to the binary when building with automake was odd. You fixed it using a static library, but there is no need for a whole videopreview library. I modified the code so that the static mplayerthumbscfg library is now used, which is linked to both the module and the binary. As a result, mplayerthumbs.kcfgc is processed once.
Instead of set_source_files_properties, I used set_property( SOURCE ) because this allows APPEND. You can wonder why I set mplayerthumbs.cpp as dependence instead of mplayerthumbs.h – that's because of an bug in KDE3_ADD_KCFG_FILES, which as OUTPUT sets only a cpp file and does not list the header.
Because there is a translation template and a component is defined in TDE Weblate, PO files can be created automatically from TDE Weblate. Therefore, we need to have rules for building translations even though there are no PO files now.
Because there were more changes, I made an amend to your commit instead of review:
1. The entire part with the `add_custom_command` and `set_source_files_properties` for `mplayerthumbs.kcfgc` was ineffective.<br/>Since `mplayerthumbs.kcfgc` is not a source file for object compilation (such as cpp=>o), `set_source_files_properties` has no effect on such a file and therefore custom command has never been executed.
2. Since `mplayerthumbs.kcfgc` was listed as the source for two libraries, it was actually processed 2×. If the previous custom command would work, it would be processed 3×.
3. Linking the module to the binary when building with automake was odd. You fixed it using a static library, but there is no need for a whole `videopreview` library.<br/>I modified the code so that the static `mplayerthumbscfg` library is now used, which is linked to both the module and the binary. As a result, `mplayerthumbs.kcfgc` is processed once.
4. Instead of `set_source_files_properties`, I used `set_property( SOURCE )` because this allows `APPEND`.<br/>You can wonder why I set mplayerthumbs.cpp as dependence instead of mplayerthumbs.h – that's because of an bug in `KDE3_ADD_KCFG_FILES`, which as `OUTPUT` sets only a cpp file and does not list the header.
5. Because there is a translation template and a component is defined in TDE Weblate, PO files can be created automatically from TDE Weblate. Therefore, we need to have rules for building translations even though there are no PO files now.
mplayerthumbsconfig ( small gui to set mplayer path) is supposed to build with videopreview as a module/plugin (videopreview.so) but couldn't manage to build It that way, therefore I build videopreview both as a module and a static library, then mplayerthumbsconfig is linked with the static lib.
videopreview.so is still provided as a module for other apps to use (which one?).
There is no po files at the moment.
Strips over thumbnails is enabled by default with automake, since we usually build with all options, I've set It up with ${WITH_ALL_OPTIONS}, Slavek, if you prefer that option set "on" or "off" by default, just tell me, I'll change It.
On the 2014-03-01 Darell reported bug 1986 related to mplayerthumbsconfig and videopreview as a shared lib by the way.
Because there were more changes, I made an amend to your commit instead of review:
add_custom_command
andset_source_files_properties
formplayerthumbs.kcfgc
was ineffective.Since
mplayerthumbs.kcfgc
is not a source file for object compilation (such as cpp=>o),set_source_files_properties
has no effect on such a file and therefore custom command has never been executed.mplayerthumbs.kcfgc
was listed as the source for two libraries, it was actually processed 2×. If the previous custom command would work, it would be processed 3×.videopreview
library.I modified the code so that the static
mplayerthumbscfg
library is now used, which is linked to both the module and the binary. As a result,mplayerthumbs.kcfgc
is processed once.set_source_files_properties
, I usedset_property( SOURCE )
because this allowsAPPEND
.You can wonder why I set mplayerthumbs.cpp as dependence instead of mplayerthumbs.h – that's because of an bug in
KDE3_ADD_KCFG_FILES
, which asOUTPUT
sets only a cpp file and does not list the header.a4a23a811f
.