|
Notes |
|
|
(0018418)
|
|
Bill Hoffman
|
|
2009-11-15 15:20
|
|
|
Alex can this be done with on of the extended makefile generators? |
|
|
|
(0018421)
|
|
Alex Neundorf
|
|
2009-11-15 15:27
|
|
This feature request is about this IDE: http://www.codelite.org/ [^]
This is the first time I hear about CodeLite.
Does CodeLite support projects which already have existing makefiles ?
Alex
|
|
|
|
(0018422)
|
|
Alex Neundorf
|
|
2009-11-15 15:37
|
|
I just downloaded and built it, but now when I try to install it to /opt/codelite/, it still wants to install some files to /usr/lib/.
I don't feel like doing this.
Alex |
|
|
|
(0018423)
|
|
Alex Neundorf
|
|
2009-11-15 15:38
|
|
It also doesn't seem to honor DESTDIR.
Alex |
|
|
|
(0018459)
|
|
Pablo.Tolosa
|
|
2009-11-16 17:03
|
|
This IDE is very simillar to codeblocks, the project files have extension .project and the workspace .worspace. These files are some type of xml.
Is a cross platform IDE, windows/Linux/Mac. I think that this IDE can have a great future because is very similar to Visual Studio and runs in Linux and can import Visual Studio projects.
I hope this helps, if you need any feedback, please don't hesitate to contact me.
Thanks. |
|
|
|
(0018460)
|
|
Eran Ifrah
|
|
2009-11-17 01:06
|
|
Hi Alex,
codelite supports projects with an existing makefiles.
If you like to add support for codelite, I can give you all the details you need about the format of the project / workspace files (both are XML files)
Please contact me (eran dot ifrah at gmail dot com)
(Author of codelite IDE) |
|
|
|
(0018461)
|
|
mmiguelx2
|
|
2009-11-17 03:32
|
|
Hi,
I think Codelite is great and has a lot of potential.
It would be great if CMake could generate Codelite projects.
I just wanted to express my support and thanks for these two great projects (CMake and Codelite). |
|
|
|
(0018488)
|
|
Alex Neundorf
|
|
2009-11-19 16:24
|
|
Hi Eran,
it would be nice if you could have a look at this yourself :-)
As examples you could have a look at cmGlobalKdevelopGenerator.h/cxx and also
cmExtraEclipseCDT4Generator.h/cxx. Both derive a class from the base class defined in mExternalMakefileProjectGenerator.h.
With these extra generators, at first cmake generates makefiles as it always does, and after that the Generate() function of the extra generator is called. There you can e.g. iterate over all the targets and write that information into IDE-specific project (xml) files.
Alex |
|
|
|
(0018489)
|
|
Alex Neundorf
|
|
2009-11-19 16:24
|
|
Is there a way to install CodeLite e.g. into /opt/ ? It seems --prefix=/opt didn't work.
Alex |
|
|
|
(0018517)
|
|
Alex Neundorf
|
|
2009-11-22 10:30
|
|
Ah, ok I got it installed.
./configure --prefix=/opt/codelite --plugins-dir=/opt/codelite/lib/codelite
I think the plugins-dir should be adjusted automatically if a prefix is given (and no explicit plugins-dir).
Alex |
|
|
|
(0018518)
|
|
Alex Neundorf
|
|
2009-11-22 10:46
|
|
I had a look at the files codelite generates for a project.
codelite-test.tags - are this results from C++ parsing ?
codelite-test.mk, codelite-test_wsp.mk - the makefiles which build the project ?
codelite-test.project - I guess this one contains targets etc. ?
codelite-test.workspace - list of projects belonging to this workspace ?
codelite-test.workspace.session - ?
I guess codelite regenerates the makefiles above whenever it thinks this is necessary. Can this be avoided in some way ?
With a cmake generator for codelite, definitely a way to use makefiles generated by something else must be available.
How is this done for the qmake plugin ?
The other option would be to write a full cmake generator for CodeLite, but this would be a lot of work. If instead the generator can be realized using Makefiles + extra project files this would be much more feasible.
Alex |
|
|
|
(0018524)
|
|
Eran Ifrah
|
|
2009-11-22 11:07
|
|
Hi Alex,
*.tags is the parsing result and can be ignored
<project>.mk & <workspace>_wsp.mk are the generated makefiles
Like you figured: the .workspace only specifies the list of project + which one is the active one (property of a project)
It also defines the various 'workspace' targets, for example: Debug, Release.
and for each target (configuration) which projects to build and which configuration to use in each project.
The .project file is the file containing the real data: virtual folder, compiler settings, plugins data (can be ignored by cmake) list of files, link options debugger settings and other goodies.
the .session -> auto generated file and can be ignored by CMake
codelite re-generates the makefile whenever a setting in modified for a project (e.g. adding new file, adding new define etc)
Qmake plugin is a special plugin which overrides codelite internal makefile generator: it captures the 'generate makefile' event and "tells" codeilte that he is taking care for this, so this step is skipped by codelite. What the qmake plugin does, is it generates .pro file, run QMake for it construct the build command for codelite to execute based on the qmake generated makefiles. |
|
|
|
(0018526)
|
|
Alex Neundorf
|
|
2009-11-22 11:35
|
|
Hmm. So I see two options:
1) You write a full project generator for codelite for cmake, which will generate fully working .project files for codelite, including different compilers (not only gcc, but e.g. also Intel), different languages (at least C, C++, Fortran and assembler would be nice) and support for cross compiling, and codelite will need a command line mode so that a nightly test can check whether the generated project file still works with codelite.
2) You enhance codelite so that it can import projects with existing makefiles, and call these existing makefiles when building the project. Then we can add an extra generator for codelite to cmake as it has been done for CodeBlocks, Eclipse and KDevelop. This is much less work, and much easier work, and I'm willing to help with this.
It would also be really good if I could not only build the whole project, but different targets inside one project in codelite (or I just didn't find how to do it).
Alex |
|
|
|
(0018527)
|
|
Eran Ifrah
|
|
2009-11-22 11:39
|
|
|
|
|
(0018528)
|
|
Alex Neundorf
|
|
2009-11-22 12:15
|
|
I uploaded three files which give you a basic starting point for a codelite generator in cmake.
Copy the two cmExtraCodeLite.* files into the Source/ directory of cmake from cvs HEAD, and apply the patch.
Then you have a new generator available named "CodeLite - Unix Makefiles".
This generator generates normal makefiles and after that calls the virtual function cmExtraCodeLiteGenerator::Generate().
This should then create codelite project files, but it does not do that yet. Instead it simply iterates over all directories, targets and source files and prints them to stdout, so you can see how you get to all the information from within cmake.
This is the point where you should put the code which actually writes the codelite project files.
I guess they will need custom rules for the project-wide build and clean targets, and you can add custom targets.
The project file will also have to tell codelite that it should not try to generate makefiles itself.
Alex |
|
|
|
(0019866)
|
|
techsgin
|
|
2010-03-13 11:38
|
|
Hi All
I have implemented a basic CodeLite Generator.
It does the trick.
See:
codelite_generator_v1.tar.gz
You can download CMake 2.6.4 Source.
Then apply the patch in codelite_generator_v1.tar.gz
Rebuild cmake
that’s it.!
Many thanks to Alex Neundorf for making the initial template.
Regrads
TechSgin |
|
|
|
(0019867)
|
|
techsgin
|
|
2010-03-13 12:37
|
|
Hi All
Please use version codelite_generator_v2.tar.gz
fixed: hardcoded cmake command.
I have changed the cmake command, so now it is useing the source tree & binary tree of the home directory for all projects.
Now you can click "Run Other" (executes cmake from the IDE) from any project.
Regrads
TechSgin |
|
|
|
(0019868)
|
|
techsgin
|
|
2010-03-13 12:50
|
|
Hi All
i have uploaded versio v3 codelite_generator_v3.tar.gz
changed the IDE "Run Other" to run cmake-gui instead of cmake.
Now you can click "Run Other" (executes cmake-gui from the IDE) from any project.
Regrads
TechSgin |
|
|
|
(0019869)
|
|
techsgin
|
|
2010-03-13 14:38
|
|
Hi All
I have uploaded version v4 codelite_generator_v4.tar.gz
Changed: Changed the “Configuration Name” to “CMake” instead of “Debug” & “Release”.
*Note: You can still choose debug or release using cmake.
Fixed: default path to the program binary for execution.
TechSgin |
|
|
|
(0019870)
|
|
techsgin
|
|
2010-03-13 15:51
|
|
Hi All
I have uploaded version v5 codelite_generator_v5.tar.gz
add: you can now compile and preprocess a single file
TechSgin
|
|
|
|
(0019875)
|
|
techsgin
|
|
2010-03-14 12:48
|
|
Hi All
I have uploaded version v6 codelite_generator_v6.tar.gz
add: used custom target for install
TechSgin |
|
|
|
(0019876)
|
|
Alex Neundorf
|
|
2010-03-14 14:01
|
|
Nice work :-)
I had a quick look, it looks good in general, but it's not yet ready for inclusion.
Some comments:
* the coding style needs some adjustments, CMake is quite strict with this:
* maximum line length is 79 characters, no matter whether it is code, comment, a string or anything else
* no tabulators at all allowed
* curly braces are indented 2 spaces, the code inside the space is not indented once more, correct example:
if (foo)
{
do_something();
}
* CreateNewProjectFile() is quite long, it would probably be a good idea to split somehow into smaller functions
Beside that, some comments to the actual code:
* don't put "make" into the project file, get the cmake variable CMAKE_MAKE_PROGRAM instead and put this into the project file
* don't put cmake-gui directly in the project file, but either use CMAKE_EDIT_COMMAND, or the target "make edit_cache", or check whether there is a "cmake-gui" in the same directory as CMAKE_COMMAND (i.e. cmake).
* don't hardcode "CompilerType=\"gnu g++\", but instead check CMAKE_C_COMPILER_ID and CMAKE_CXX_COMPILER_ID for the type of toolchain. For gcc/g++ this is "GNU".
* I'm not sure the commands for building single files are correct. They must be executed in the directory where the target, to which they belong, are executed. In the code I see $(ProjectPath) instead.
* why is there something about a qmake plugin hardcoded ?
Alex |
|
|
|
(0020506)
|
|
Alex Neundorf
|
|
2010-05-01 14:44
|
|
Hi,
are you still working on it ?
Do you need any help with it ?
Alex |
|
|
|
(0020507)
|
|
Alex Neundorf
|
|
2010-05-01 15:06
|
|
I could set up a git clone of the cmake repository on http://gitorious.org [^] for the development. Would this help ?
Alex |
|
|
|
(0026458)
|
|
Alex Neundorf
|
|
2011-05-07 06:56
|
|
Hi,
haven't heard from you since a long time.
Are you still interested ?
Alex |
|
|
|
(0026578)
|
|
Alex Neundorf
|
|
2011-05-25 16:05
|
|
The original reporter did not respond for more than one year now.
I will not add this generator to cmake without somebody supporting it.
|
|
|
|
(0034862)
|
|
Gopalakrishna Palem
|
|
2013-12-24 22:17
|
|
I am looking into the code attached to this and did tidy up little bit - removing the hard codes and reducing the line-widths.
Seems to be working fine - except for one thing.
Each target in the cmake should become one individual project in CodeLite.
Right now, enumeration is happening on GlobalGenerator->GetProjectMap(), which will end-up creating all targets of makefile under single CodeLite project, which is not suitable for setting manipulations in the IDE.
If someone could give the code to enumerate on CMake targets (rather than on cmake projects), then this should be close the final goal.
- GK
http://gopalakrishna.palem.in/ [^] |
|
|
|
(0034863)
|
|
Eran Ifrah
|
2013-12-25 06:27
(edited on: 2013-12-25 06:29) |
|
Hello,
I have uploaded a patch based on the latest techsgin work (v6 zip)
It improves the following:
- The codelite configuration name is using the same as CMAKE_BUILD_TYPE (or "Debug" by default and not hard coded "CMake"
- Make the code compile against the latest git head
- Fixed project format and removed wrong info placed into the project
- Removed obsolete XML properties from codelite's project file
Hope, you can test and apply it
I have tested the patch locally on my codelite build (codelite is now being built using cmake on Linux/OSX so I tested this layout with the new generator and it seems to be working perfectly)
EDIT:
I read that you did not apply the previous patches since no one was willing the take ownership on this generator, well, I am more than happy to support it
Thanks,
Eran (codelite IDE author)
|
|
|
|
(0034864)
|
|
Gopalakrishna Palem
|
2013-12-25 07:02
(edited on: 2013-12-25 07:04) |
|
Eran,
Thank you for the patch. My changes earlier I was working on, are similar to your patch, except I made the "make" and "gnu g++" not hard-coded as Alex was suggesting. For example, I used the below strings,
std::string compiler = this->GetCBCompilerId(mf);
std::string make = mf->GetRequiredDefinition("CMAKE_MAKE_PROGRAM");
std::string cmakegui = mf->GetRequiredDefinition("CMAKE_EDIT_COMMAND");
in the build and clean commands. The GetCBCompilerId() definition I have provided below at the end of this note. Perhaps it can go into the patch, if it is ok with you.
I see just two more points to go to get this one complete:
1. The "Rebuild" option right now is empty - may be it can be put same as "clean & build" ?? somehow
2. I was not happy with all "targets" in a CMakeLists being endup as single project in CodeLite. Just Like VS, users would prefer each target in the CMakeLists, appearing as its own project in CodeLite.
I can see that the for loop is going over "GlobalGenerator->GetProjectMap().begin()" in the "cmExtraCodeLiteGenerator::Generate()" method, where as it is preferred to go over all "targets" of the CMake. But I am not sure of the right API for that. Perhaps Alex can help with that, and we all can close this one as success.
/********************* ***********************/
// Translate the cmake compiler id into the CodeBlocks compiler id
std::string cmExtraCodeLiteGenerator::GetCBCompilerId(const cmMakefile* mf)
{
// figure out which language to use
// for now care only for C and C++
std::string compilerIdVar = "CMAKE_CXX_COMPILER_ID";
if (this->GlobalGenerator->GetLanguageEnabled("CXX") == false)
{
compilerIdVar = "CMAKE_C_COMPILER_ID";
}
std::string hostSystemName = mf->GetSafeDefinition("CMAKE_HOST_SYSTEM_NAME");
std::string systemName = mf->GetSafeDefinition("CMAKE_SYSTEM_NAME");
std::string compilerId = mf->GetSafeDefinition(compilerIdVar.c_str());
std::string compiler = "gnu g++"; // default to g++
if (compilerId == "MSVC")
{
compiler = "msvc8";
}
else if (compilerId == "Borland")
{
compiler = "bcc";
}
else if (compilerId == "SDCC")
{
compiler = "sdcc";
}
else if (compilerId == "Intel")
{
compiler = "icc";
}
else if (compilerId == "Watcom")
{
compiler = "ow";
}
else if (compilerId == "GNU")
{
compiler = "gnu g++";
}
return compiler;
}
/*********************************************/
Thank you,
GK
http://gopalakrishna.palem.in/ [^]
|
|
|
|
(0034865)
|
|
Eran Ifrah
|
|
2013-12-25 07:17
|
|
Hello GK,
For now, codelite (as of codelite 5.4/5.3) supports 5 compilers:
gnu gcc,gnu g++, clang, clang++ and VC++
So we can omit watcom, icc and all non supported compilers
( BTW, does GetSafeDefintion() is the proper for avoiding crash when assigning NULL to std::string? )
I will update the patch accordingly (i.e. I will remove all hard coded strings, like "make", compiler name etc)
Also, unlike you, I am pretty happy with using a project per CMakeLists.txt file
Ofc, it will be even better if we could create a project per target, but its less important
Eran |
|
|
|
(0034866)
|
|
Gopalakrishna Palem
|
|
2013-12-25 07:49
|
|
Not much sure about GetSafeDefinition(), Eran. Found it being used in other generators, so may be that's the right way to do it.
I agree with you about one project per file as a starting point.
But in my case I am moving from VS to CodeLite - and trying to get around the code across single project is much cumbersome, than when each target is treated as its own project and thereby (hopefully) gets its own list of macro values and compiler settings. Specially the project tree view.
For example, I am trying to use CodeLite for building my project CFugue (http://gopalakrishna.palem.in/CFugue.html [^] ), where the same code-base gets compiled into two different targets - one DLL and other static LIB, with just few macro definition changes. This is to ensure that both .Net users (through P/Invoke) and C++ users can benefit from the same API. In such case, it would become almost impossible without having that "different project" distinction.
Though I agree, getting atleast one project per one CMakeLists file first is a good step.
Thank you,
GK
http://gopalakrishna.palem.in [^] |
|
|
|
(0034867)
|
|
Eran Ifrah
|
|
2013-12-25 08:19
|
|
I have uploaded second version of the patch:
- Fixed code indentation to fit cmake standard (I am using astyle with the --style=whitesmith switch enabled)
- "make" is not longer hard coded
- Use CMake APi to determine compiler that should be used by codeite |
|
|
|
(0034868)
|
|
Eran Ifrah
|
|
2013-12-25 08:20
|
|
Forgot to mention:
Rebuild command is now populated as well with: make clean && make -j8 |
|
|
|
(0034869)
|
|
Eran Ifrah
|
|
2013-12-25 09:36
|
|
|
Uploaded version 3.0 which fixes a case where the configuration name was set to an empty string |
|
|
|
(0034870)
|
|
Eran Ifrah
|
|
2013-12-25 10:55
|
|
Uploaded v4.0:
Use NoConfig when no configuration is specified (via CMAKE_BUILD_TYPE)
Make sure all code line are less than 80 chars
Add Ninja and NMake generators
Do not suggest NMake and MinGW on non MSW platforms
Generate the workspace with relative project file paths
Eran |
|
|
|
(0034871)
|
|
Alex Neundorf
|
|
2013-12-25 11:36
|
|
I didn't have a look at the code yet.
JUst some comments:
GetSafeDefinition() does basically the same as GetDefinition(), with the difference that it never returns a NULL-pointer, it returns an empty string then instead.
I guess you didn't hard code the "-j8" ?
E.g. for the Eclipse generator there is cmake code in CMakeFindEclipse...cmake, which detects the number of CPUs and sets then a cmake cache variable accordingly, so users get a sensible default but can still override it.
One project per target... sounds a bit strange. Usually there should be one project per build-tree or one project per project()-call. I.e. there would be one project if no project()-call at all exists (one project is created automatically), and multiple otherwise.
The maximum line length is 79, not 80.
You probably want to put your copyright in the file header.
To actually get this into cmake, you need to publish your changes in a git tree, e.g. on cmake's git "stage". Starting on github is also ok:
http://www.cmake.org/Wiki/CMake/Git/Develop [^]
Thanks for your work
Alex |
|
|
|
(0034872)
|
|
Eran Ifrah
|
|
2013-12-25 12:48
|
|
Hi Alex,
I have submitted push access request
Eran |
|
|
|
(0034873)
|
|
Eran Ifrah
|
|
2013-12-25 13:01
|
|
Hi Alex,
After re-reading your comment, I am not sure I understood it correctly.
I intereperted it as "go and submit a push request" so my updates will go into cmake's git repository
I might be wrong here though...
Can you please clarify this?
Eran |
|
|
|
(0034874)
|
|
Alex Neundorf
|
|
2013-12-25 15:34
|
|
You should get access to cmake git, via an key etc.
Then you should push your change in a branch to the cmake "stage", and from there merge it into next.
Then it will go into master.
This should be documented on the link I posted above. |
|
|
|
(0034875)
|
|
Eran Ifrah
|
|
2013-12-26 01:38
|
|
Thanks Alex,
Until I get the push access, I have uploaded the final patch version (v5.0)
which includes the following:
- The number of jobs to run is determined by the current OS number of CPUs (physical * logical)
- All lines are now < 79 chars
- Added my name to the copyrights header
- Use GetSafeDefinition in all places instead of GetDefinition()
- The files of a project are now separated into 2 virtual folders (include & src)
- Project files are kept relative to the project path as required by codelite
- Use the proper build commands for the various generators (i.e. use 'ninja -jN' for Ninja, 'nmake' for 'NMake Makefiles' and Unix/MinGW makefiles will use 'make -jN' (in all cases using the CMAKE_MAKE_PROGRAM definition)
Eran |
|
|
|
(0034876)
|
|
Gopalakrishna Palem
|
|
2013-12-26 02:24
|
|
Alex,
One project per target is not strange at all. Cmake's definition of project and IDE's definitions are projects are different.
Visual studio does this all the time. So, I checked the VS generator code and found this below. Perhaps this same can be adapted for CodeLite and other IDEs too:
void cmGlobalVisualStudio7Generator::WriteTargetsToSolution()
{
....
for(OrderedTargetDependSet::const_iterator tt =
projectTargets.begin(); tt != projectTargets.end(); ++tt)
{
....
std::string project = target->GetName();
std::string location = expath;
this->WriteExternalProject(fout,
project.c_str(),
location.c_str(),
target->GetProperty("VS_PROJECT_TYPE"),
target->GetUtilities());
written = true;
}
}
As can be seen above, the targets are enumerated and each target generates one individual project in the VS-IDE so that the targets can be independently manipulated.
To understand this better, from the IDE perspective think about this scenario: you want to see all and only the files that are involved a particular target in the IDE - how can IDE show them if the target is not "logically" treated as a different project?
In a "single project for all targets" mode, it would be impossible to know which file is participating in which target (unless you are the creator of cmakelists file, which usually is not the case when working on collaborated open-source projects). Hence the request for this.
I know you would suggest to use different project name for different cmakelists, but usually projects that were earlier using some other build system and now adapting cmake system, do not follow this and tend to just dump all targets into a single large cmakelists file at the root of their dir. Hence the problem.
Thank you,
GK
http://gopalakrishna.palem.in [^] |
|
|
|
(0034878)
|
|
Alex Neundorf
|
|
2013-12-27 06:15
|
|
I'll leave it up to Eran how to create projects.
Eran: did you check whether everything works correctly if the build and/or source dir contain spaces ?
Is there a way to use CodeLite in an automatic test to check whether the generated project file is correct ? |
|
|
|
(0034879)
|
|
Alex Neundorf
|
|
2013-12-27 06:19
|
|
The patch v5 contains whitespace errors:
~/src/CMake/cmake> git apply ~/Downloads/codelite-generator-v5.0.patch
codelite-generator-v5.0.patch:25: trailing whitespace.
codelite-generator-v5.0.patch:49: trailing whitespace.
void cmExtraCodeLiteGenerator::GetDocumentation(cmDocumentationEntry& entry,
codelite-generator-v5.0.patch:89: trailing whitespace.
codelite-generator-v5.0.patch:90: trailing whitespace.
if (strcmp(mf->GetStartOutputDirectory(),
codelite-generator-v5.0.patch:99: trailing whitespace.
warning: squelched 31 whitespace errors
warning: 36 lines add whitespace errors.
Lines must not have trailing whitespace, and there must be no tab characters anywhere. |
|
|
|
(0034880)
|
|
Eran Ifrah
|
2013-12-27 06:43
(edited on: 2013-12-27 06:45) |
|
Hi Alex,
In codelite 5.3 I have introduced the codelite-make{.exe} which can be used to generate makefiles for nightly build (without the overhead of needing X server)
So probably just running this utility will verify that the project and workspace files are valid
A nice side effect of this utility is that in case of a corrupted project or workspace files, it will print an error message to stderr starting with "[ ERROR ]" prefix
Using codelite-make:
For example, lets assume I have a workspace file named "TestBook.workspace", which contains a single project named "MyProject" and 2 configurations "Debug" and "Release" so running this command from a terminal:
codelite-make --workspace=/path/to/TestBook.workspace --project=MyProject --config=Debug
Should generate a Makefile file + it will print the build command to use from the command line (this is printed to stdout):
cd D:\src\TestArea\TestBook && mingw32-make -e -f Makefile
In case of an error, we will get something like:
D:\src\TestArea\TestBook>codelite-make --workspace=TestBook.workspace --project=TestBook --config=Debug
[ERROR ] Could not find project TestBook. Invalid project name 'TestBook'
Hope this can be used for testing purposes.
BTW, I am still waiting for the push access... probably due to the holidays, it will take longer than expected
But I would really love this patch make it into CMake (ofc, I will maintain it if needed)
Eran
|
|
|
|
(0034881)
|
|
Eran Ifrah
|
|
2013-12-27 06:52
|
|
Updated to version 0.6 without whitespaces
Eran |
|
|
|
(0034882)
|
|
Alex Neundorf
|
|
2013-12-27 11:43
|
|
Hi Eran,
codelite-make looks really good for testing.
You may have a look at Tests/CMakeLists.txt and try to add a test there, which more or less does a find_executable(codelite-make), and if found, adds a test which generates a codelite project for a simple project (hello-world style), and then runs codelite-make on it.
This day every night it could be ensured that the generated files are at least not completely broken.
A few weeks ago, the documentation format has been changed for cmake.
It uses now reStructured text. Have a look at Help/generator/.
Thanks
Alex |
|
|
|
(0034883)
|
|
Eran Ifrah
|
|
2013-12-27 14:42
|
|
Added CodeLite.rst file (copied from Codeblocks, with simple find/replace)
patch v7 uploaded
Eran |
|
|
|
(0034888)
|
|
Alex Neundorf
|
|
2013-12-29 00:10
|
|
Hopefully your git account won't take too long, but I also think this is most probably due to the holidays.
If you want to do even more, you can have a look at the source_group() command.
As far as I know, this is currently only supported by the Visual Studio generators (and people actually also use it). It can be used to create groups or hierarchies, and put the source files into these groups.
These groups appear in Visual Studio as some tree somewhere.
I don't have Visual Studio here, so I cannot tell you in detail.
If you think this can be also done in CodeLite, you may have a look at the implementation of this command and see whether you can create such groups also in CodeLite. |
|
|
|
(0034889)
|
|
Gopalakrishna Palem
|
|
2013-12-29 00:42
|
|
Source_groups are virtual folders inside VS. We constantly use Source-Groups across all our products to organize the files. For example, into virtual folders inside workspace like "generated files", "header files", "qt forms", "moc files" etc....
GK
http://gk.palem.in/ [^] |
|
|
|
(0034895)
|
|
Eran Ifrah
|
|
2014-01-02 12:45
|
|
|
|
|
(0040430)
|
|
tobias.wood
|
|
2016-02-03 08:29
|
|
Hello,
I guess this is the right place to post this. I am experimenting with CodeLite. My project includes a header library target (add_custom_target) and some copy-only script files. The CodeLite generator ignores these files so they don't show up in my Project. This is very frustrating, because even though I can manually add them to the project every time I edit the CMakeLists.txt file the Project is rebuilt and they disappear.
Thanks,
Toby |
|
|
|
(0041619)
|
|
Kitware Robot
|
|
2016-06-10 14:27
|
|
Resolving issue as `moved`.
This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page. |
|
cmExtraCodeLiteGenerator.h (1,416) 2009-11-22 12:08
cmExtraCodeLiteGenerator.cxx (2,752) 2009-11-22 12:08
codelite.patch (1,431) 2009-11-22 12:09
codelite_generator_v1.tar.gz (4,424) 2010-03-13 11:33