lldb detection & broken non-SFTP build

[petah]

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

Code: Select all

NAMES liblldb.so  liblldb-3.5.so

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

[eranif]

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

Agreed

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)

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

[petah]

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.

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