Thread: [CEDET-devel] EDE CMake status
Brought to you by:
zappo
From: Alastair R. <ar...@in...> - 2012-02-13 03:27:20
|
Hi CEDET folks, It seems that the wheels of legal bureaucracy turn fairly slowly but nonetheless I now have the appropriate paperwork for contributing to CEDET on file with the FSF. My main goal at present is to contribute to EDE, specifically to add CMake support. I have a branch which I have been using quite successfully and I know of at least one other who has been able to do likewise. https://code.launchpad.net/~arankine/+junk/ede-cmake So I guess I'd like to get some further review comments, specifically whether it is suitable for merging into trunk. There is some existing code from ede-cpp-root which I have factored out into a separate base class for reuse by the ede-cmake-project class. There is no support for parsing CMakeList.txt files but I am (slowly) working towards this. |
From: Alastair R. <ara...@gm...> - 2012-02-13 03:10:35
|
Hi CEDET folks, It seems that the wheels of legal bureaucracy turn fairly slowly but nonetheless I now have the appropriate paperwork for contributing to CEDET on file with the FSF. My main goal at present is to contribute to EDE, specifically to add CMake support. I have a branch which I have been using quite successfully and I know of at least one other who has been able to do likewise. https://code.launchpad.net/~arankine/+junk/ede-cmake So I guess I'd like to get some further review comments, specifically whether it is suitable for merging into trunk. There is some existing code from ede-cpp-root which I have factored out into a separate base class for reuse by the ede-cmake-project class. There is no support for parsing CMakeList.txt files but I am (slowly) working towards this. |
From: Nikolaus D. <de...@in...> - 2012-02-20 02:45:18
|
Hi Alistair Alastair Rankine <arankine <at> gmail.com> writes: > My main goal at present is to contribute to EDE, specifically to add CMake support. I have a branch which I > have been using quite successfully and I know of at least one other who has been able to do likewise. > > https://code.launchpad.net/~arankine/+junk/ede-cmake > > So I guess I'd like to get some further review comments, specifically whether it is suitable for merging > into trunk. I'm very interested in this. Can I test it? Where are the 4 files supposed to go, and is there some documentation of what features are supported and can be tested? > > There is no support for parsing CMakeList.txt files but I am (slowly) working towards this. > This would be truely awesome, but sounds very complicated to do fully. Maybe an alternative would be to generate configuration files from cmake, like they do for Eclipse. Anyways, I'd love to here more. Best, Nikolaus |
From: Thomas R. <ric...@gm...> - 2012-03-01 22:30:16
|
Hi everyone Nikolaus Demmel <demmeln <at> in.tum.de> writes: > > Hi Alistair > > Alastair Rankine <arankine <at> gmail.com> writes: > > > My main goal at present is to contribute to EDE, specifically to add CMake > support. I have a branch which I > > have been using quite successfully and I know of at least one other who has > been able to do likewise. > > > > https://code.launchpad.net/~arankine/+junk/ede-cmake > > > > So I guess I'd like to get some further review comments, specifically whether > it is suitable for merging > > into trunk. > > I'm very interested in this. Can I test it? Where are the 4 files supposed to > go, and is there some documentation of what features are supported and can be > tested? To use the files, add them on a directory listed in load-path, as usual. An example of configuration is in the comments at the bottom of ede-cmake.el. > > > > > There is no support for parsing CMakeList.txt files but I am (slowly) working > towards this. > > > > This would be truely awesome, but sounds very complicated to do fully. Maybe an > alternative would be to generate configuration files from cmake, like they do > for Eclipse. > I had the same idea: it would be a lot easier to get the information from cmake directly. So I started to write an external generator for cmake, based on the one for codeblocks. The code is available on github: https://github.com/Niluge-KiWi/CMake/tree/ede-generator How to use it: cmake . -G "EDE - Unix Makefiles" It will generate the usual makefiles tree on the build directory, but will also add elisp files: one per cmake project (<project_name>.ede), and one per CMakeLists.txt (ede.local.generator.el) This represents the cmake internal data structure: Projects have several local generators, which are associated with each CMakeLists.txt file in the source. For each local generator, we have the include paths and targets it handles. This code is only a prototype: the idea was to see what information is available, and how to extract it to make it available from emacs. The result is: we easily have everything we need. This still needs quite some work, but this will depend on how exactly we use the information in ede. I'm not familiar with ede, so I don't know how to proceed on the ede side. I'm currently trying to understand Alastair's code and look where we could use such information. -- Thomas Riccardi |
From: Alastair R. <ar...@in...> - 2012-03-04 23:16:20
|
On 01/03/2012, at 4:24 PM, Thomas Riccardi wrote: > I had the same idea: it would be a lot easier to get the information from cmake > directly. So I started to write an external generator for cmake, based on the > one for codeblocks. > > The code is available on github: > https://github.com/Niluge-KiWi/CMake/tree/ede-generator > > How to use it: > cmake . -G "EDE - Unix Makefiles" > > > It will generate the usual makefiles tree on the build directory, but will also > add elisp files: one per cmake project (<project_name>.ede), and one per > CMakeLists.txt (ede.local.generator.el) Very interesting! I hadn't thought of doing it that way, but I can see it would work in certain contexts. It might be worth explaining a bit about my intentions with the EDE CMake mode. Basically I want the EDE CMake mode to enable CEDET features on a CMake project without requiring extensive configuration. In an ideal world this would work completely automatically on a fresh checkout of a CMake project - and would allow the project to be built/run directly from within EDE. Some of this functionality is already present; you can check out a CMake project, load it in EDE, and use it to locate/manage a build directory, then invoke CMake itself to generate the makefiles, and finally issue the build command. This all works for the projects that I have tested it on. It has several limitations at present, the main one being that it assumes that each source directory corresponds to a target with the same name. This means that if you want to use the target functionality of EDE, your project needs to conform to this convention. Hence the next step (for me) is to parse the CMakeLists.txt files to extract the list of targets, and associated source files. Being an imperative language, there is no way to parse this file entirely without actually emulating CMake itself (or hooking into CMake, as you have done...) However for the purposes of extracting information relevant to EDE, I don't think this is needed. In most cases the targets are easy to identify with "add_library" (and similar) commands. Some CMake projects create macro wrappers for the add_library commands. Hence on a per-project basis we may want to enable aliases for the CMake commands so that we can identify targets and associated source files. For example, the LLVM codebase (which I am using as a representative example of a CMake project) defines a "add_llvm_library" macro which is a simple wrapper for add_library. The arguments to this macro define both the library name (ie the target) and all associated source files. Hence all that is required for the LLVM project is to enable an alias add_llvm_library which can be used to parse the project CMakeLists.txt files. There are obviously many cases in which this won't work. However I suspect that in most cases it will be good enough. It certainly would be useful for the open source projects that I've looked at (eg LLVM) as well as my $WORK project. In principle, other project information such as preprocessor definitions can be extracted from CMakeLists.txt files using such a simpleminded technique. I need a way to persist these per-project settings (eg a list of alias macros). The current approach is to configure this stuff in elisp ahead of time. A better solution would be a file which contained only enough information to help the EDE CMake parser make sense of the CMakeLists.txt files. For now I'm sticking with the former, as it's easier. So that's the current status. I'm still getting my head around the semantic parser infrastructure (see previous emails) so there isn't much progress to show on the CMakeLists.txt parsing, but I will keep plugging away at it. |
From: Dave A. <da...@bo...> - 2012-09-19 22:24:04
|
on Sun Mar 04 2012, Alastair Rankine <arsptr-AT-internode.on.net> wrote: > On 01/03/2012, at 4:24 PM, Thomas Riccardi wrote: > > Some of this functionality is already present; you can check out a > CMake project, load it in EDE, and use it to locate/manage a build > directory, then invoke CMake itself to generate the makefiles, and > finally issue the build command. This all works for the projects that > I have tested it on. > > It has several limitations at present, the main one being that it > assumes that each source directory corresponds to a target with the > same name. This means that if you want to use the target functionality > of EDE, your project needs to conform to this convention. > > Hence the next step (for me) is to parse the CMakeLists.txt files to > extract the list of targets, and associated source files. > > Being an imperative language, there is no way to parse this file > entirely without actually emulating CMake itself (or hooking into > CMake, as you have done...) However for the purposes of extracting > information relevant to EDE, I don't think this is needed. In most > cases the targets are easy to identify with "add_library" (and > similar) commands. > > Some CMake projects create macro wrappers for the add_library > commands. Exactly. That's why I might want to use Thomas' generator... > Hence on a per-project basis we may want to enable aliases for the > CMake commands so that we can identify targets and associated source > files. > > For example, the LLVM codebase (which I am using as a representative > example of a CMake project) defines a "add_llvm_library" macro which > is a simple wrapper for add_library. Oh! Oh! Could you post the Project.ede files for LLVM, pretty please? > The arguments to this macro define both the library name (ie the > target) and all associated source files. Hence all that is required > for the LLVM project is to enable an alias add_llvm_library which can > be used to parse the project CMakeLists.txt files. But target declaration macros and functions in CMake are not always so simple. ...On the other hand, needing a special version of CMake is not so attractive. The KDevelop3 and Eclipse Generators appears to spit out XML, which would be relatively easy to parse, and presumably would only contain predictable elements. It might be better to parse one of these formats than to try to parse the CMake. > There are obviously many cases in which this won't work. However I > suspect that in most cases it will be good enough. It certainly would > be useful for the open source projects that I've looked at (eg LLVM) > as well as my $WORK project. > > In principle, other project information such as preprocessor > definitions can be extracted from CMakeLists.txt files using such a > simpleminded technique. > > I need a way to persist these per-project settings (eg a list of alias > macros). The current approach is to configure this stuff in elisp > ahead of time. An example of that configuration would be very helpful to someone wanting to use your work. > A better solution would be a file which contained only enough > information to help the EDE CMake parser make sense of the > CMakeLists.txt files. For now I'm sticking with the former, as it's > easier. > > So that's the current status. Well, that was 6 months ago... and it looks like you've made a few commits since then. Care to post an update? -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost |
From: Eric M. L. <eri...@gm...> - 2012-02-14 02:45:58
|
Hi Alastair, That sounds great. I looked quickly at your link below, and wonder if there are some missing features in core EDE that would help. The locate-fcn was the first thing that really stood out for me. I should be able to dig in with more detail this weekend. Thanks Eric On 02/12/2012 10:11 PM, Alastair Rankine wrote: > Hi CEDET folks, > > It seems that the wheels of legal bureaucracy turn fairly slowly but nonetheless I now have the appropriate paperwork for contributing to CEDET on file with the FSF. > > My main goal at present is to contribute to EDE, specifically to add CMake support. I have a branch which I have been using quite successfully and I know of at least one other who has been able to do likewise. > > https://code.launchpad.net/~arankine/+junk/ede-cmake > > So I guess I'd like to get some further review comments, specifically whether it is suitable for merging into trunk. > > There is some existing code from ede-cpp-root which I have factored out into a separate base class for reuse by the ede-cmake-project class. > > There is no support for parsing CMakeList.txt files but I am (slowly) working towards this. > > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Cedet-devel mailing list > Ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-devel > |
From: Alastair R. <ar...@in...> - 2012-03-05 04:35:19
|
On 13/02/2012, at 8:45 PM, Eric M. Ludlam wrote: > That sounds great. I looked quickly at your link below, and wonder if there are some missing features in core EDE that would help. The locate-fcn was the first thing that really stood out for me. I should be able to dig in with more detail this weekend. Hi Eric, did you have any further thoughts on this? There are a couple of things to point out here: As you identified, I changed expand-filename-impl slightly. There are two reasons for this: Firstly, I wanted to allow the locate-fcn to return nil if it couldn't locate the file, in which case we fall back to searching the include-path, and then calling back up to the base class if that fails. I think this is more intuitive and allows the locate-fcn to just handle special cases. Secondly I wanted the locate-fcn to be able to query state from the project. This is because on some projects, files can be located outside of the project root (eg in the build directory for generated files). The current build directory is stored in a slot on the project object, so in this case I pass through the project as a parameter to the locate-fcn. In retrospect I guess I could have the locate-fcn use ede-current-project instead... (I will look into this) Another thing to point out is that I took the existing ede-cpp-root project and split out the include path and spp tracking into a base class (i called it ede-cpp-project) which ede-cmake uses. IMHO this would be a useful change to apply to EDE. Let me know if there is anything else I can clear up for you. |
From: Eric M. L. <eri...@gm...> - 2012-03-09 02:08:49
|
On 03/04/2012 11:35 PM, Alastair Rankine wrote: > On 13/02/2012, at 8:45 PM, Eric M. Ludlam wrote: > >> That sounds great. I looked quickly at your link below, and wonder if there are some missing features in core EDE that would help. The locate-fcn was the first thing that really stood out for me. I should be able to dig in with more detail this weekend. > > Hi Eric, did you have any further thoughts on this? > > There are a couple of things to point out here: > > As you identified, I changed expand-filename-impl slightly. There are two reasons for this: > > Firstly, I wanted to allow the locate-fcn to return nil if it couldn't locate the file, in which case we fall back to searching the include-path, and then calling back up to the base class if that fails. I think this is more intuitive and allows the locate-fcn to just handle special cases. > > Secondly I wanted the locate-fcn to be able to query state from the project. This is because on some projects, files can be located outside of the project root (eg in the build directory for generated files). The current build directory is stored in a slot on the project object, so in this case I pass through the project as a parameter to the locate-fcn. In retrospect I guess I could have the locate-fcn use ede-current-project instead... (I will look into this) > > Another thing to point out is that I took the existing ede-cpp-root project and split out the include path and spp tracking into a base class (i called it ede-cpp-project) which ede-cmake uses. IMHO this would be a useful change to apply to EDE. > > Let me know if there is anything else I can clear up for you. Hi, I've been busy trying to keep up with the mailing list, so hadn't looked into cmake much since. Sorry about that. When you create a class that inherits from another and you want to override a slot with some new initform (such as configurations), you don't need to specify any slot attributes beyond the initform. Specifying the other slot attributes, like :initarg or :custom increases the chance that things break if your baseclasses change. You can also just opt to change the default value in initialize-instance. Ok, now I'm going to summarize what I currently understand about your effort to make sure I have my facts straight: You have pulled the ede-cpp-project baseclass up out of ede-cpp-root to handle the useful bits of C++ code handling. Your subclass no longer depends on ede-cpp-root, but instead uses the shared core for c++ handling. You still use your project by instantiating ede-cmake-cpp-project in the users .emacs file? You are starting to develop code to extract useful information out of cmake for use in the project type. I definitely like the idea based on that, but I am becoming wary of building off of ede-cpp-root based on some of the other ideas going by on the mailing list. ede-cpp-root project, while it has some nice features for C++, is designed to be a static configuration in your .emacs file, while a CMake project type with dynamic reading from cmakefiles would/could be dynamically loaded, and based on more recent email, apparently have real targets and structure? If your end goal is to use cmake to find real targets, and build a project file to keep your project data, then ede-cpp-root (or its derivitive) is not the right spot to build from. If you just need a cmake customized flavor of ede-cpp-root, where there is no real knowledge of the project, then what you have is good, though I think ede-generic might be a preferred base for your system if you have a mix of goals, since it is designed to have a persistent configuration file with users tweaks in it, and also includes dynamic target creation, but that depends on the level of configuration you want. I'm having a hard time guessing the end goal. It looks like you have some nice cmake/configuration tricks for doing builds, but it sounds like there is interest in using cmake to create some sort of ede config file. If that is the end goal, you are probably better off starting from the core ede project base classes, or we can extend ede-generic in some way to help with the building of sources outside the project directory. What do you think your end-goals are? Fortunately, the way you wrote most of your project, swapping out baseclasses won't really affect much of your code if you want to change things. As such, you can probably delay deciding what to do till later. Did that help, or just make things more confusing? I know I confused myself trying to type this. Eric |