2012/10/25 François ANDRIOT francois.andriot@free.fr

Le 25/10/2012 20:21, Darrell Anderson a écrit :

What about a small comment for each WITH_* option in root CMakeList.txt

...

...

by which BUILD_* option(s) it is used? I can take it up...

Sure. :) To me most options are straightforward, but a few need additional information. Possibly too, expand the stdout message that displays when an option is not supported correctly.

Darrell

Adding comment is a good idea. While building TDE I also looked at CMakeLists.txt and sometimes I saw things like: "WITH_GADU: enables the gadu support" OK this is pretty straightforward, but, what exactly is "gadu" ? What TDE functionality will I lose if I build without it ? Some explanations about options would be appreciated.

Verbose documentation with a list of affected functionality for each option would be great... But it requires quite a lot of time and knowledges... I propose at least only a list of affected modules for each option. IMO it also helps to understand what each option is propoused to. Here is one for tdebase. (Also I fixed a typo)

FIX: in WITH_SAMBA the last one should be kcontrol not samba.

A request: would you please create the patch comparing CMakeLists.txt to CMakeLists.txt.new rather than CMakeLists.txt to CMakeLists.txt.orig?

The patch works the same but I get confused. As you are adding comments my mind expects to see "additions" rather than "subtractions." I'm getting too old (and lazy) to have to think in abstract. :)

Thanks! :)

Darrell

I've noticed that but decided not to send the third letter in a raw... anyway it could be applied by passing -R option to patch...

Yup, I know, but I have my dyslexic moments. Plus, thinking in reverse makes my head hurt. :)

here is the normal one... + some fixes

Thanks!

Suggested changes:

simultaneosly concurrently

requider required

thumbnail (two places) thumbnails

affects <nothing yet> supports hardware detection when libhal is not installed

Darrell

affects <nothing yet>

supports hardware detection when libhal is not installed when it will be pushed to git it supposed to be changed... but before that you shouldn't mislead anybody...

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.

also, here is a small patch to tdeartwork...generally there is nothing to describe. but for the tick...

tdeartwork suggested change:

AS IS:

NOTE: all this flags control that scrensavers are to be compiled/installed and nothing more.

CHANGE TO:

NOTE: These flags control how screensavers are compiled/installed.

Darrell

here are kdegraphics comments.

Dne po 29. října 2012 Darrell Anderson napsal(a):

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.

Comments look good - this have my support. However, at this time I do not plan that I would backport it into 3.5.13-sru (though not rule it out.). I hope to progress to the R14. :)

Slavek --

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. :)

seems at least I need to attach a spell checker to vim... it will significantly simplify your job =))

Here comes tdenetwork comments.

...

Here comes tdenetwork comments.

sorry, haven't saved the file... here is the right one.

Pushed to GIT in commit 058a95c5 with only one editorial change: deleting the word "description" in the GSM line.

Thanks!

Darrell