I took a look through your project. There is some good stuff going on
here. More comments below.
On 08/25/2011 08:31 AM, Alastair Rankine wrote:
> So I've continued to work on this, and I think I've actioned most of
> the feedback from last time. What follows is a bit of a brain dump.
> As a reminder the code is here:
> Further to the previous discussions, I've decided that ultimately the
> single project root is probably not the way to go, the main reason
> being that CMake tends to want a CMakeLists.txt file per
> subdirectory. Eventually I'd like to be able to parse this file and
> extract the target information, and also I'd like to support multiple
> targets per CMakeLists.txt file. Hence I think a hierarchal project
> structure is probably best.
I agree. The hierarchical case is the default form that EDE was built
for. The single root version is relatively new and is an effort to
simplify some kinds of projects.
> So I'm moving in that direction. Here's what I've done, comments
> - Change my project type to not inherit from ede-cpp-root-project.
> This is partially to support the above goal, but also to solve an
> immediate problem with the creation of targets; as noted by David I
> was hijacking some methods on ede-cpp-root-target. Instead
> ede-cmake-cpp-project inherits directly from ede-project. I've looked
> at ede-generic and I think it is best to just use ede-project as the
> base class for now.
That seems like a good idea. Several kinds of projects all support
C/C++ in slightly different ways. Getting good support for all would be
> - Provided an implementation of ede-find-target, which lazily-creates
> an instances of ede-cmake-cpp-target. Unlike the
> ede-cpp-root-project, targets are indexed by relative path to the
> root - not sure if this is a great idea or not, but I intend to do
> something similar with subprojects when I come to support that.
If you have a project per directory, this is the right way to go.
For subprojects, if you look in ede-proj.el, this is the biggest project
type in EDE, and supports linking subprojects together. See
ede-proj-load for the snippet that builds a tree of projects by
searching the directory hierarchy. The base EDE code can already find a
project, and find the root in the file system. This snippet then loads
all those subprojects in.
> - Another difference from ede-cpp-root-target is that I chose to
> support a link from the target to its parent project. Again not sure
> if it's a great idea, but it does seem to reduce the need to call
Hmmm. I don't remember much about this.
> - In order to retain the support for semantic I've copied the
> relevant code out of ede-cpp-root-project. This seems to be code
> which has general utility and I could imagine that it would make a
> handy mixin class for other project types that want to support c/c++.
> Maybe the standard EDE projects could be refactored in this way?
> - The ede-expand-filename-impl method is also lifted from
> ede-cpp-root-project but I came across a potential issue which needed
> fixing. In the code below from ede-cpp-root-project, we only check
> the include-path if the locate function is nil, which doesn't seem
> right to me? In my version we check the include-path if the locate
> function is non-nil but does *return* nil. (Maybe I'm missing
> something about how this should work?)
> (let* ((lf (oref proj locate-fcn)) (dir (file-name-directory (oref
> proj file)))) (if lf (setq ans (funcall lf name dir)) (if
> (ede-cpp-root-header-file-p proj name) ....
If I remember this rightly, it is assumed that the user supplied locate
function is faster and more robust than our puny lisp implementation, so
we just defer to that.
That thing is just a hack to allow users to easily add in their own
routines without having to create their own EDE classes. Since you are
using CMake explicitly, it is unlikely a user would need such a
customization at all.
> - Added a build custom target function/menu. This simply prompts for
> the target name and passes it to the build tool. A better solution
> would create a target object and build that - but this would require
> additional EDE support. I'm not sure what the status of this is, it
> looks like there once was some movement in this area for EDE, what is
> the intention here?
Once you implement subprojects, and targets based on parsing the CMake
file, then the compile target option becomes very simple to implement.
ie- it us just that method call. There is a build menu that is auto
populated from the target lists, so you wouldn't need to create you own
if you use CEDET from bzr trunk, and edit files in CEDET, you can see
how it works since CEDET uses EDE for its project management.
> - Beginnings for support of project-run-target. In order to do this
> I've had to create a cmake-build-tool class which encapsulates the
> build tool specific behaviour. For example Visual Studio build
> directories are laid out slightly differently to the GNU Make ones,
> and you need to be able to navigate them in order to find the
> binaries to launch.
> So progress is being made. Here's the list of features I'm planning:
> - Multiple project support. This possibly requires me to understand
> the project directory inode caching stuff. - Multiple targets per
The inode stuff is just a bunch of magic you can ignore. See the
ede-proj.el loader I mentioned above. Once you create the subprojects
on load, the file caching system is automatic.
> project. Some of these targets can be automatically-generated based
> on the build tool. For example, when generating makefiles for the GNU
> Make build tool, CMake creates a "foo/fast" target to go along with
> the "foo" target. Other targets could be entered by the user (as per
> custom targets), or, better still, parsed directly out of the
> CMakeLists.txt file. - Complete support for project-run-target and
> project-debug-target - Add support for the per-file GNU Make targets.
> When this build tool is used, each file in the project has targets
> for compiling, preprocessing, and disassembling. With this we should
> be able to trivially add support for flymake mode. - Multiple build
> directories per configuration type. There's no reason why you can't
> have more than one Debug build directory, for example. - (Eventually)
> support for parsing CMakeLists.txt
For parsing CMakeLists.txt, consider just writing a semantic parser for
it. There is already a parser for Makefiles, so perhaps it will be
similar. You can then write simple code that says "find all the
targets", and semantic will take car of the rest.
For example, open any Makefile, and do:
M-: (semantic-find-tags-by-class 'function (current-buffer))
where targets are interpreted as functions for Makefiles.