Re: Fwd: Re: Calligra translations are enabled

On Friday, December 17, 2010, Cyrille Berger Skott wrote:
> installed at the same time. All in all, it is a big effort, and it has a

it's often easier to understand these things when looking at actual numbers.

the two things needed are:

* unique library prefixes
* unique header install prefix

there are 31 CMakeLists.txt in calligra/libs/, not all of which have build 
targets in them (but most do). the target names would need to be changed in 
each, e.g. instead of "flake" sth like "caligraflake".

that's boring work, but it's a day's effort by the clock on the wall. it's a 
few hours of actual editting CMakeList.txt files, the rest would be watching 
the build to ensure success.

the install prefixes also need to be cleaned up; right now each library just 
installs a bunch of headers right into ${INCLUDE_INSTALL_DIR}, sometimes in 
subdirs though they are not very well named imho (styles/? seriously, no other 
project might come up with that?) in any case, this can be fixed in 
calligra/CMakeLists.txt by appending a prefix, e.g. calligra/, to 
${INCLUDE_INSTALL_DIR}. the internal structure would remain the same, so no 
major changes there.

in calligra/CMakeLists.txt all the prefixes for the libraries are included, 
and those wouldn't change for the apps in the calligra repo. so no work needed 
there.

the last issue is naming of the binaries, and that's easy using open source 
"common law": whoever the recognized maintainer of the application is gets to 
keep the naming. whoever forks away from the maintainer gets to change, which 
means in the case of Calligra that some work on kword needs to be done. 
(looking in the repo, it hasn't been). the other renames that Calligra has 
commited to (stage, numbers, etc.) are not completed either.

there are 782 "target_link_libraries" lines in the CMakeLists.txt in calligra. 
they would need to be adjusted to reflect library name changes, such as 
"komain" to "calligramain" (that lib appears 154 times in the CMakLists.txt). 
fortunately, this stuff is trivially scriptable:

for i in `find . -name CMakeLists.txt`;
    do perl -pi -e 's,komain,calligramain,g' $i;
done

(yes, that'll screw up the CMakeLists.txt for the komain library itself, but 
just git checkout that one file after the above is run)

so it means making a list of library name changes and scripting the resulting 
changes to the other CMakeLists.txt files.

then there are things like cmake/modules/FindKOfficeLibs.cmake.in that would 
need to be transition to FindCalligraLibs.cmake.

so .. a fair amount of work indeed, but it's all CMakeLists.txt workso not 
particularly hard and not particularly risky either. it can even happen in a 
git branch while everyone else continues to work on the code.

you also have people here like Brian who are just looking for some way to get 
involved. to quote his email:

"I don't know what all the issues are.
I'm new here, and have been holding back on contributing, mostly because I
don't know which project I'm supposed to help with; Project A, B or 6 of
9."

now, assuming Brian is actually telling it like it is, maybe he would like to 
take this CMakeLists.txt work on so that Calligra becomes fully self-contained 
on install. as a new contributor, he'll need some help and will certainly have 
questions as he goes .. but it's perfect "first time contributor" work because 
it isn't deeply technical _and_ Brian will get an awesome overview of the 
entire codebase.


> near null gain.

i think the gain can be summarized as:

* Calligra really stands on its own two feet, with its own name
* opportunity clean up of the somewhat sloppy header install targets
* opportunity to bring a new contributor (in this case Brian) into the project


obviously, it'd be up to the Calligra team to decide if it is, ultimately, 
worth it.

personally, i'd want to have my project using my project's name, and new 
contributors are worth their weight in gold. or valgrind logs. whichever your 
prerfered metric is. ;)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks

_______________________________________________
koffice-devel mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/koffice-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)

iEYEABECAAYFAk0LvrQACgkQ1rcusafx20PVbACdGSBJQYif3nj8APx2ZOWiYLIo
hpcAniqzEJ3RxWD/O/RDX1KqFnBcc1F2
=IJAu
-----END PGP SIGNATURE-----