2012/10/29 Darrell Anderson <humanreadable@yahoo.com>
Great!
Suggested changes:
adds support for t1lb -a library -> adds support for t1lb, a library
fixed
loose -> lose
fixed
this library is used only for set default parametrs -> this library sets default parameters
not sure... library got a lot more features, but here it is used only for what one...
changed to: «this library is only used to set some default parameters of paper according to system settings.»
Seems it sounds better
planed -> planned
fixed
but it wasn't implemented or was rejected -> but hasn't yet been ported
A quick history of cmake in Trinity:
The cmake ports are an ongoing process. There are additional packages where the cmake port was started but have not matured to a point of usability. All packages contains some rudiments of porting to cmake, but this is a long term process. One of our R14 goals is to complete the ports for some more packages. Note too that with each port the build process must be tested on different distros, toggling the options to test the results, etc. That is one reason we don't delete the automake files because they serve as a long-term reference for the cmake ports.
I know that...
Although the existing cmake ports are in good shape, not every single build option was ported. Mostly this is a result that the people porting the builds did not have access to those options. Thus we notice an occasional missing build option. Browse the bug tracker to notice where we have tagged some of those absences (for example, amarok). Thus in the example of the comment for kviewshell(plugins/djvu), a reasonable plan is to investigate the original automake build options. If the option was supported in automake but was not ported to cmake, then a bug report would be appropriate. If the option never was supported in automake, perhaps a bug report might still be in order to provide that support. :)
Side comments: even if you are using 3.5.13.1, notice that in the R14 development branch that there has been significant package and app renaming. Thus kdegraphics is now tdegraphics. Therefore some comments might seem appropriate in 3.5.13.1 but will not apply in R14. Hence the continuing review of these changes. Eventually I'll push them to GIT. Slavek will decide whether to backport the changes to 3.5.13.1 but often with these types of changes he has to cherry pick, which is more work than just backporting the whole patch. :)
For this comments I'm also quickly watching through the source codes and autotools files . Generally I'm just greping for \(WITH\|HAVE\)_<FLAG> and looking how/where they are used. I'm using generally git version for this comments. All comets are entirely based on sources not on the actual user experience.
So when I'm saying «It wasn't implemented» it means «It wasn't implemented at all» not only in cmake.
2012/10/29 Darrell Anderson
<humanreadable@yahoo.com>
Suggested changes to tdebase:
setted concurantly -> set concurrently
if it is so, when WITH_SHADOW will have no effect -> WITH_PAM will override WITH_SHADOW
next options are also required -> then the following options are also required
> TDEHW is already in GIT. Anybody who builds from GIT can use that
> option. I use the option to build in Slackware 14.0, which
> no longer supports HAL.
>
> hm... I see... Tim has used different inclusion guards for that and defined them only in
> config.h.cmake... what's why I haven't noticed them... it seems to be a temporary solution,
> isn't it?
Permanent. :) Not everybody is building and using packages from GIT for the simple reason that GIT is, technically, the development/experimental branch. Thus many people might not notice these changes. I have been using the GIT branch as my primary desktop environment for several months. Therefore I'm more intimate with these changes than most people using Trinity. :)
I'm talking about renaming flags and some other code-clean-related issues, not about functionality stuff...IMHO now those tons of ifdefs in kioslave/media/mediamanager seems unclear and bad-readable... Also there are some other cmake-related readability issues...
what about of moving hal-interaction functionality to tdehw lib? and make it an another backend additional to udev?
But it seems thats this talk is for another thread...
Description: The TDEHW libs provide hardware detection formerly provided by HAL.
It is still not clear enough for me what tdehw will be in future e.g. after 1 or 2 releases... so I won't add it now myself... if you wish you can add it before pushing to git...
I have been providing technical writing services for three decades. Thus, I have an eye to catch these things. :) I'm a tad lazy with my correspondence in this list, but for the official documentation I have high standards. So don't worry too much. I could make the changes myself and push to GIT but that would not provide you an opportunity to know what could or should be changed. I also don't believe I should make changes without your knowledge because that action would be construed as subversive and not courteous. :) My only goal is to ensure Trinity documentation is professional, not to be an anal ass about what you propose. ;) There are others in the project who do not speak/write English natively. I watch for that and try to help, just as I am doing here. Conversely, I don't speak/write other languages and I rely on them to ensure texts are translated correctly. :)
Adding the comments to the CMakeLists.txt files is a great idea. As long as we are patient with one another the patches will get pushed to GIT. :)