CodeLite IDE

Hi Eran,

On Debian Jessie (testing) there are two versions of LLVM, clang and lldb: 3.4 and 3.5, the former is default. When installing 3.5, the names are llvm-3.5, clang-3.5 and lldb-3.5. Patching ./LLDBDebugger /CMakeList.txt at the top to have it search for fixes it, but Debian jessie is going to become stable pretty soon so it may not be worth the trouble.

CL no longer builds with -DENABLE_SFTP=0. It used to complain the symbol was getting redefined repeatedly during a build but still build, but now it's a hard error. I couldn't make out the logic; it seems the are at least 3 variables: ENABLE_SFTP affects WITH_SFTP which calls add_definitions(-DUSE_SFTP=XXX).

Tracing CMake is fine but tracing Make slowed to a crawl, and the build aborted while processing the Subversion2 plugin later. Not sure if SVN is a new dependency but I was running with -j5 so the cause may be upstream which means WAY WAY upstream given how verbose Make is in debug mode, so I just hacked away but commenting out as many plugins as possible.

Not really a "solution", but it beats having to wade through CMake's alien syntax, and m4, not to mention some projects now use a Python front-end (or Google's "gradle" whose NDK support sucks), one tool spewing ever more data into the nex... when the only sensible solution is Lua! (obviously )

Anyway hopefully codeLITE isn't losing its slender shape because fast startup time is its greatest quality.

Over & out!

-- p

petah wrote:fixes it, but Debian jessie is going to become stable pretty soon so it may not be worth the trouble.

Agreed

petah wrote:CL no longer builds with -DENABLE_SFTP=0. It used to complain the symbol was getting redefined repeatedly during a build but still build, but now it's a hard error. I couldn't make out the logic; it seems the are at least 3 variables: ENABLE_SFTP affects WITH_SFTP which calls add_definitions(-DUSE_SFTP=XXX).

Its just a glitch with the recent commits with the changes I have made to the SFTP plugin and its infrastructure, this is now fixed (I also removed all the double definition of USE_SFTP from the PHP CMakeLists.txt and forced it to honour the ENABLE_SFTP command line switch)

petah wrote:Tracing CMake is fine but tracing Make slowed to a crawl, and the build aborted while processing the Subversion2 plugin later. Not sure if SVN is a new dependency but I was running with -j5 so the cause may be upstream which means WAY WAY upstream given how verbose Make is in debug mode, so I just hacked away but commenting out as many plugins as possible.

Not really a "solution", but it beats having to wade through CMake's alien syntax, and m4, not to mention some projects now use a Python front-end (or Google's "gradle" whose NDK support sucks), one tool spewing ever more data into the nex... when the only sensible solution is Lua! (obviously )

CMake does not have the best syntax in the world, but it is the most documented, used and popular build system you can find around.
I took the time and learned it and I don't regret doing so, I am actually considering switching the build system at work from using qmake to cmake

Eran

eranif wrote:

petah wrote:CL no longer builds with -DENABLE_SFTP=0.

Its just a glitch with the recent commits with the changes I have made to the SFTP plugin and its infrastructure, this is now fixed (I also removed all the double definition of USE_SFTP from the PHP CMakeLists.txt and forced it to honour the ENABLE_SFTP command line switch)

Cool thx, rebuilding now.

eranif wrote:

petah wrote:it beats having to wade through CMake's alien syntax, and m4, not to mention some projects now use a Python front-end (or Google's "gradle" whose NDK support sucks), one tool spewing ever more data into the nex... when the only sensible solution is Lua! (obviously )

CMake does not have the best syntax in the world, but it is the most documented, used and popular build system you can find around.
I took the time and learned it and I don't regret doing so, I am actually considering switching the build system at work from using qmake to cmake

The trouble is that new build tools keep on getting introduced with a totally new (revolutionary) syntax. They get hyped up, adopted by some portion of people but never enough to become a standard... just enough to become a nuisance Technical merit hardly matters. I'd love to be proven wrong... in the meantime I rejoice that C++ has found a common voice led by a Microsoftee, no less, and doing a bang-up job!

cheers,

-- p