CodeLite IDE

Downloaded latest sources from SVN (5928).
Compiling on Debian Wheezy
Output of gcc -v I had compiled and install wx294 locally. However, I had used a couple of local changes when compiling wx294 that seemed to have a rather pronounced effect on CodeLite.
1) I had used -std=c++11 in the CXXFLAGS
2) I used "--enable-stl --enable-std_string_conv_in_wxstring"

Getting CodeLite configured and to compile was "entertaining".

The configure went without a hitch. But make would immediately fail with an error message complaining about the missing "-std=" tag that had been used on wx294 compile. Each time make would fail, I would end up changing the configure file to include the "-std=" directive for a particular component of CodeLite (changes in configure were made in gcc, clang, indexer sections).

The compile would also halt on error complaining about missing a reference to wxPrintf and wxFPrintf. I think these missing references are a consequence of the changes upstream in wx294 (inclusion of Unicode - see wxW Unicode Overview) and my enabling std::string. I could find no references to wxPrintf/wxFPrintf in the wx294 documentation (but wxprintf.cpp exists in the source). I ended up changing the CodeLite sources by replacing the wxPrintf/wxFPrintf statement with its C equivalent in a few places to complete the compile:

• codelite/CodeLite/cpptoken.cpp (line 52),
  codelite/CodeLite/file_logger.cpp (line 68),
  codelite/Plugin/macrosdlg.cpp (line175),
  codelite/codelite_clang/clang.cpp (4x line 24,220,251,300)
  codelite/UnitTestCPP/unittestcppoutputparser.cpp (lines 150 - 152)

There was one other issue with the compile that cropped up. In the file:
codelite/sdk/wxshapeframework/src/wxxmlserializer/PropertyIO.cpp (line 165) g++ complained about something below this call (ambiguity with isnan(double&)).
I ended up changing this line to . Could this be an upstream problem?

So far, the compile has proceed with only a few warnings here and there (unused or uninitialized variables).
Let's see what happens when the compile finishes and can it execute?
--- more to follow ---

==== SUCCESS ====
Build and Install Completed!

A couple of issues jumped out during the compile...
codelite/DatabaseExplorer/SqlCommandPanel.cpp (line 210) was flagged as an error during compiling. The wx294 documentation shows the declaration for as deprecated.
Line was replaced with new version .

codelite/CallGraph/uicallgraphpanel.cpp (line 107) was also flagged during compiling. wxGrid::GetRows is not shown in the documentation. Could this instead be a reference to wxGrid::GetNumberRows? If so, the line becomes . But if the number of rows is zero-based counting, should the range for DeleteRows be...?

One last issue I noticed...
The install did put a desktop file in place but no icon appears for the menu item. It appears from looking at the codelite.desktop file that the $prefix path was not generated properly for the Icon entry. Line 5 of the desktop file: is the "default" install/prefix path. But if the user puts a different $prefix value during configure, then I suspect this is not picked up during the install of the desktop file. Real minor and easy to fix.

Nice stuff!!!

can you please place all your fixes into a patch file and send it to me (or attach it here)

Thanks,
Eran

Eran,
Attaching file...

A couple of caveats:
- I got a warning about using the directive compiling a C file. I may have put an extra "-std=" directive where it doesn't need to be.
- The patch file is rather "polluted" because I had a setting enabled on Geany to strip extra spaces on the ends of lines
- includes change for m_grid->DeleteRows(0, m_grid->GetNumberRows() - 1)

So, question...
Why use fprint instead of cout?

I'm trying to tracked down the line in the configure file that causes the link to the icon file to be incorrect.
configure (line 1230) If I get this (big maybe - haven't explored sed much), its doing a replacement of a placeholder with the actual value.
But something is going wrong here....the default value of $prefix is being used.

...and if I look up...way, way up....
configure (line 1190) overwrites the existing value... and does not correct for users selection

Edit---
if we move the sed lines below the if/else statements, then prefix should be set properly and usable.
Attaching an update patch file...

scottfuz wrote: ...
I had compiled and install wx294 locally. However, I had used a couple of local changes when compiling wx294 that seemed to have a rather pronounced effect on CodeLite.
1) I had used -std=c++11 in the CXXFLAGS
2) I used "--enable-stl --enable-std_string_conv_in_wxstring"
...
The compile would also halt on error complaining about missing a reference to wxPrintf and wxFPrintf. I think these missing references are a consequence of the changes upstream in wx294 (inclusion of Unicode - see wxW Unicode Overview) and my enabling std::string. I could find no references to wxPrintf/wxFPrintf in the wx294 documentation (but wxprintf.cpp exists in the source). I ended up changing the CodeLite sources by replacing the wxPrintf/wxFPrintf statement with its C equivalent in a few places to complete the compile:

• codelite/CodeLite/cpptoken.cpp (line 52),
  codelite/CodeLite/file_logger.cpp (line 68),
  codelite/Plugin/macrosdlg.cpp (line175),
  codelite/codelite_clang/clang.cpp (4x line 24,220,251,300)
  codelite/UnitTestCPP/unittestcppoutputparser.cpp (lines 150 - 152)

There was one other issue with the compile that cropped up. In the file:
codelite/sdk/wxshapeframework/src/wxxmlserializer/PropertyIO.cpp (line 165)

Code: Select all

if( wxIsNaN(value) )

g++ complained about something below this call (ambiguity with isnan(double&)).
I ended up changing this line to

Code: Select all

if( std::isnan(value) )

. Could this be an upstream problem?

The common threads here are wxString, using the stl compile directive in wxWidgets and this is all local to my machine.
Probably a usage issue on my end. I'll punt this over to wxWidgets Forum and see what the guru's there have to say.

Thanks for the help!