Package Details: codelite 17.0.0-0

Git Clone URL: https://aur.archlinux.org/codelite.git (read-only, click to copy)
Package Base: codelite
Description: Cross platform IDE for C, C++, Rust, Python, PHP and Node.js written in C++
Upstream URL: https://codelite.org/
Keywords: C++ Editor IDE
Licenses: GPL
Conflicts: codelite-unstable
Provides: codelite
Submitter: None
Maintainer: uffe
Last Packager: uffe
Votes: 174
Popularity: 0.000372
First Submitted: 2008-08-01 09:11 (UTC)
Last Updated: 2024-07-12 13:32 (UTC)

Dependencies (21)

Required by (3)

Sources (6)

Pinned Comments

uffe commented on 2016-09-26 11:42 (UTC) (edited on 2020-07-27 18:21 (UTC) by uffe)

ATTENTION: read this before flagging this package out-of-date

This package "codelite" represents the stable release of the codelite project.

I do not consider the "Weekly Builds" from http://downloads.codelite.org/ as stable releases (neither does the codelite project)

Generally speaking - this package will not be updated before the codelite release/download page (https://downloads.codelite.org/) have a new stable release published.

Please respect that - Thanks

PS: to clear up a recent misunderstanding - this does not mean that I won't accept patches that is needed for stable codelite to build against refreshed libraries etc

PS: I have added new "codelite-unstable" package to AUR that follows the weekly/latest builds from the codelite project.

Latest Comments

« First ‹ Previous 1 .. 3 4 5 6 7 8 9 10 11 12 13 .. 17 Next › Last »

nickname commented on 2015-10-06 06:01 (UTC)

Indeed. But I would have to re-compile it... (and it takes sometime) If the problem persist it will be the only way out in the next release anyway so...

uffe commented on 2015-10-05 11:47 (UTC)

You could try to change -DENABLE_LLDB=1 into -DENABLE_LLDB=0 in the PKGBUILD file. That should work with lldb-3.7.x

nickname commented on 2015-10-05 10:46 (UTC) (edited on 2015-10-05 10:47 (UTC) by nickname)

found it! It was caused by "lldb 3.7.0" I downgrade it to 3.6.2-4 to make it work. more specific: (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /usr/bin/codelite [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". 13:43:55: Warning: Mismatch between the program and library build versions detected. The library used 3.0 (wchar_t,compiler with C++ ABI 1008,wx containers,compatible with 2.8), and your program used 3.0 (wchar_t,compiler with C++ ABI 1009,wx containers,compatible with 2.8). [New Thread 0x7fffdcad8700 (LWP 22667)] [New Thread 0x7fffd7fff700 (LWP 22668)] [New Thread 0x7fffd77fe700 (LWP 22669)] [New Thread 0x7fffd6b3e700 (LWP 22671)] [New Thread 0x7fffd633d700 (LWP 22672)] [New Thread 0x7fffd5b3c700 (LWP 22673)] [Thread 0x7fffd6b3e700 (LWP 22671) exited] [New Thread 0x7fffd533b700 (LWP 22674)] [New Thread 0x7fffd4b3a700 (LWP 22675)] [New Thread 0x7fffbffff700 (LWP 22676)] [New Thread 0x7fffbf7fe700 (LWP 22677)] [New Thread 0x7fffbeffd700 (LWP 22678)] [New Thread 0x7fffbe7fc700 (LWP 22679)] [New Thread 0x7fffbdffb700 (LWP 22680)] [New Thread 0x7fffbd7fa700 (LWP 22681)] [New Thread 0x7fffbcff9700 (LWP 22682)] [New Thread 0x7fff9bfff700 (LWP 22683)] Program received signal SIGSEGV, Segmentation fault. 0x00007fff90af30a0 in ?? () from /usr/lib/liblldb.so.3.7 (gdb) q A debugging session is active.

nickname commented on 2015-10-05 10:16 (UTC)

Does anyone have problem starting codelite the last days? Since friday it failes to start...it might be caused by an update but I am still trying to figure it out...

uffe commented on 2015-08-04 11:11 (UTC)

Done :)

nickname commented on 2015-05-12 06:34 (UTC)

@uffe thanks for your answer! Also thanks for providing us codelite!

uffe commented on 2015-05-11 22:20 (UTC)

@nickname: not all packages compile without changes - previously codelite had to be patched before it could compile on archlinix. The last releases all compile smoothly without any problems on archlinux - but it can easily break again in a later release. Not all people are comfortable with building and/or patching - they get an helping hand by using makepkg and helpers such as yaourt etc.

uffe commented on 2015-05-11 19:50 (UTC)

updated to codelite-8.0-1 (not 8.0)

nickname commented on 2015-05-11 10:17 (UTC)

Can you plz tell me what benefits I gain by using pkgbuild vs compiling it from the source by-passing pacman tool? (besides the obvious that pacman will be aware of codelite) I mean on my way to install the new version of codelite I compiled it once by downloading the code from the site and using cmake. After that (and before I run make install) I did the same by modifing the pkgbuild for 7.0-3 and it worked the same way. Anyway the pkgbuild that worked on mine laptop is: pkgname=codelite pkgver=8.0 pkgrel=1 pkgdesc="Open-source, cross platform IDE for the C/C++ programming languages" arch=('i686' 'x86_64') url="http://www.codelite.org/" license=('GPL') depends=('wxgtk' 'curl' 'webkitgtk2' 'libssh' 'xterm' 'python2' 'libedit' 'ncurses' 'valgrind' 'libmariadbclient' 'lldb') makedepends=('pkgconfig' 'cmake') optdepends=('graphviz: callgraph visualization') source=(https://github.com/eranif/${pkgname}/archive/${pkgver}.tar.gz http://repos.codelite.org/wxCrafterLibs/wxgui.zip) md5sums=('f66e5b01a7a6e60ab88110056d904a6f' '093485fcae62073ca8d0ba6ff3a5cb69') noextract=('wxgui.zip') build() { cd "${srcdir}/${pkgname}-${pkgver}" CXXFLAGS="${CXXFLAGS} -fno-devirtualize" mkdir -p build cd build cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Release -DENABLE_CLANG=1 -DENABLE_LLDB=1 -DWITH_MYSQL=1 -DCMAKE_INSTALL_LIBDIR=lib .. make } package() { cd "${srcdir}/${pkgname}-${pkgver}/build" make -j1 DESTDIR="${pkgdir}" install install -m 644 -D "${srcdir}/wxgui.zip" "${pkgdir}/usr/share/codelite/wxgui.zip" install -m 644 -D "${srcdir}/${pkgname}-${pkgver}/LICENSE" "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE" }

enkeyz commented on 2015-05-10 19:57 (UTC)

CodeLite 8.0 available. Please update the package. Thanks!