Various patches from Debian

[jcowgill]

Hi,

Firstly, thanks for creating CodeLite! I've been looking to update the official Debian / Ubuntu packages for CodeLite. I have some patches which I've applied to the Debian package and some other suggestions.

Patches
I've added each patch as a separate attachment along with an "everything.patch" file which contains all the patches cated together. All the patches are against the CodeLite master branch - commit e2238d9f118a917cc9527d440d71b76aa9f24fcb.

u1_fix-desktop.patch
Fixes the capitalisation of CodeLite in the desktop file, and adds a "Keywords" entry to the desktop file.
http://lintian.debian.org/tags/desktop- ... entry.html

u2_kill_children_syntax_error.patch
Changes the line endings in the Runtime/codelite_kill_children script from CRLF to LF. Currently running the script causes a syntax error since /bin/sh does not understand CRLF line endings.

u3_extra-library-linking.patch
Fixes the CMakeLists in DatabaseExplorer and Plugin so they link against the necessary libraries.

u4_prevent-cxx-flags-clobbering.patch
Prevents various build scripts from overwriting the contents of CMAKE_CXX_FLAGS (by appending instead). This allows extra flags to be passed to the compiler by setting the CXXFLAGS environment variable.

u5_manual-pages.patch
Added manual pages for codelite, codelite-make, and codelite_fix_files. In the Debian package, I've moved the other executables to /usr/lib/codelite since they don't seem to be designed for execution from the terminal. For this reason, I haven't bothered adding man pages for the other executables.

Suggestions / Questions
License Clarification
In the latest CodeLite release there are 2 license files (COPYING and LICENSE) and they're both (slightly) different. Which license is right?

Duplicate RPATH settings
Currently all of CodeLite's libraries have duplicate RPATH settings. Their set once for all plugins through the LINKER_OPTIONS variable, and CMake sets the RPATH again through the CMAKE_SKIP_BUILD_RPATH variable.

Run "objdump -p <library> | grep RPATH" to see RPATH settings of a library.

Plugin resources in /usr/lib
Plugin resources are stored in /usr/lib/*/codelite/resources. Since these files are architecture-independent, they should be stored in a subdirectory of /usr/share/codelite.

James

[jcowgill]

More patch files

[eranif]

I have some patches which I've applied to the Debian package and some other suggestions.

Does this means that wx3.0 has finally arrived to Debian?

In the latest CodeLite release there are 2 license files (COPYING and LICENSE) and they're both (slightly) different. Which license is right?

LICENSE

Currently all of CodeLite's libraries have duplicate RPATH settings. Their set once for all plugins through the LINKER_OPTIONS variable, and CMake sets the RPATH again through the CMAKE_SKIP_BUILD_RPATH variable.

Is this really worth fixing? i.e. is this something that would prevent codelite package in official Debian

Plugin resources are stored in /usr/lib/*/codelite/resources. Since these files are architecture-independent, they should be stored in a subdirectory of /usr/share/codelite.

repository?
This might involve some code changes, similar to the above, is this really worth fixing?


Thanks,
Eran

[jcowgill]

Does this means that wx3.0 has finally arrived to Debian?

It should be in the next Debian release and in Ubuntu 14.04.
Debian: http://packages.qa.debian.org/w/wxwidgets3.0.html
Ubuntu: https://launchpad.net/ubuntu/+source/wxwidgets3.0

Currently all of CodeLite's libraries have duplicate RPATH settings. Their set once for all plugins through the LINKER_OPTIONS variable, and CMake sets the RPATH again through the CMAKE_SKIP_BUILD_RPATH variable.

Is this really worth fixing? i.e. is this something that would prevent codelite package in official Debian

Plugin resources are stored in /usr/lib/*/codelite/resources. Since these files are architecture-independent, they should be stored in a subdirectory of /usr/share/codelite.

repository?
This might involve some code changes, similar to the above, is this really worth fixing?

Neither of these will prevent updating codelite in Debian, but I would consider them bugs. I added some simple fixes for them in the Debian package (I just symlinked the resources directory to usr/share) so they don't need to be fixed here anytime soon.

James

[eranif]

Thanks for the reply.
I will look at the patches as soon as I can.

OT question:
Is Debian or Ubuntu supports liblldb-dev package? (its the next generation debugger from LLVM/CLANG)

Eran

[jcowgill]

OT question:
Is Debian or Ubuntu supports liblldb-dev package? (its the next generation debugger from LLVM/CLANG)

There's lldb-3.3-dev and lldb-3.4-dev which should be available in the next Debian release like wxWidgets3.
https://packages.debian.org/unstable/lldb-3.3-dev

James

[eranif]

There's lldb-3.3-dev and lldb-3.4-dev which should be available in the next Debian release like wxWidgets3.

Ah, nice. These are very good news.

codelite 6.0 will have lldb debugger support, so I wondered whether I should bother and package them as well ... or use one of the pre-prepared packages

Thanks,
Eran

[DavidGH]

Hi,

Thanks for the patches. I've just applied 4 of them.

I'm not sure about u3_extra-library-linking.patch though, the one that adds GTK2_LIBRARIES to the link line. Things seem to build OK at the moment, even without DT_NEEDED (which I presume is the reason for the change). Do you know of a situation where it currently fails?

Also, if it's to go ahead, presumably it'll need GTK3_LIBRARIES for gtk3 builds...

Regards,

David

[jcowgill]

I'm not sure about u3_extra-library-linking.patch though, the one that adds GTK2_LIBRARIES to the link line. Things seem to build OK at the moment, even without DT_NEEDED (which I presume is the reason for the change). Do you know of a situation where it currently fails?

It runs because whenever the DatabaseExplorer plugin is loaded, the GTK libraries will have (coincidentally) been previously loaded by codelite itself. So it works but I got warnings from debian packaging tools which don't like this. It also looks a little fishy trying to find GTK earlier on in the file and never using the result.

Also, if it's to go ahead, presumably it'll need GTK3_LIBRARIES for gtk3 builds...

Yes you're right, I must have forgot to update the patch.

[DavidGH]

Fair enough. I've applied the amended patch.

Thanks again.