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.
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.