On Fri, May 27, 2011 at 03:58, Eric M. Ludlam <eric@...> wrote:
> On 05/22/2011 11:37 AM, kristof.ralovich@... wrote:
>>>> I had created a simple project
>>>> (https://gitorious.org/cedet-misc/cedet-test) that is meant to
>>>> illustrate my problems. I'd like to implement your suggestions in this
>>>> project to achieve my goals.
>>> This is a great example project. Thanks for assembling it. If you would
>>> like this project type to be auto-detected, the one thing EDE would need
>>> some key file at the topmost level that will tag that directory, and sub
>>> directory as being unique to your project style. For example, Android
>>> projects have an AndroidMantifest.xml that made it easy for me to create
>>> EDE project for Android.
>> The point here was that there is no top-level folder. We'd have all
>> source code in "vtkmin". Then "vtkmin-build-debug" and
>> "vtkmin-build-release" are just examples, we don't necessary have
>> these, but maybe have "vtkmin-x64-build-icc" or whatever. These build
>> folders might even be somewhere else on the filesystem, I just wanted
>> to illustrate the multiple, separate build folders (out of source)
>> What I don't know is how EDE deals with out of source builds. Maybe
>> this is the primary thing I should understand. For this, I created an
>> other version of test-bunny project this time using Automake:
>> https://gitorious.org/cedet-misc/am-test. (Once again i put two empty
>> build folders next to the source folder just for illustration.) Next I
>> tried two things:
> All EDE does is attempt to detect a specific file-name pattern that might
> reveal what kind of project something is. When detected, it associates
> files in that directory with a particular matching project type. Each
> project type can have very different sets of support features, with things
> like compilation and debugging as optional.
> Other tools can then use EDE to figure out where other files in a project
> might be.
>> 1) with automake+autoconf configure an out of source build in
>> "am-test-build-debug". Then if I open the source file
>> (am-test/src/vtkmin.cpp), EDE detects a project (I guess based on
>> am-test/Makefile.am), but i obviously can't build it, since it was not
>> configured in the source folder. Further the include paths are not
>> deducted from the makefiles in the build folder. So if I open
>> something in the source folder, how do i let EDE know where the build
>> folder is to look up e.g. the configured include paths? Shall I create
>> a Project.ede, where shallI put it, into the build folder or into the
>> source folder?
> For the automake project (where it finds automake files, as opposed to
> create them), it will find the tree of files and load them into an internal
> tree representation. It is somewhat limited in the number of automake
> features it knows how to read.
> The version where EDE makes automake files is limited, and probably won't
> support what you want to do.
>> 2) Starting from scratch, I configured am-test in the source folder
>> (run ./configure in am-test/). Then opened am-test/src/vtkmin.cpp, EDE
>> automatically recognized a project, I can build it with C-c . C. But
>> if I try e.g. M-x semantic-ia-complete-symbol in the file I get:
>> "Cannot analyze buffers not supported by Semantic". What's wrong?
>> Maybe I need to manually create a Project.ede? Are the include folders
>> still not recognized from autoconf/automake?
> This just sounds like your buffers aren't in C++ mode, or they failed to
> initialize parsing in some other way. Doing:
> M-x c++-mode RET
> should reaveal errors if there are any, or put the buffer into a good state.
>>>> PS 2: I had read Alex Ott's great article
>>>> (http://alexott.net/en/writings/emacs-devenv/EmacsCedet.html) and
>>>> other hints for cmake
>>>> but I'd like to reach a more straight forward solution. Also I have a
>>>> working setup of the above using hardcoded ede-cpp-root-project.
>>> I think you will need to specify in more detail what "straight forward"
>>> means. ede-cpp-root is often sufficient to bring in some project with
>>> build systems.
>> By straight forward I mean: e.g. in a configured build folder I create
>> (for now manually is ok) a Project.ede specifying the configured
>> include paths, defines, etc. Then I say something like "M-x
>> ede-set-active-project build-folder/Project.ede" and from then on, I
>> can edit source files in the source folder that are contained in this
>> build with the proper include lookups and defines all the advantages
>> of code-completion, etc.
> You should never need to write a Project.ede file. You either use
> M-x ede-new RET
> to create a project of the right type, or EDE will just find your automake
> files, and the Project.ede file is not needed. Based on your explanation,
> you are probably best off hand-writing your automake files to make sure it
> does what you want, and EDE will just follow that.
thanks for your answers, now I realized that I understand about EDE
even less. I'll try to formulate concrete questions in the hope that
based on your suggestions it will be possible for me to implement
How do I parse a Makefile with Semantic? Let's say,
- I'd like to list all targets that are defined in a Makefile.
- I'd like to list the dependencies of a target.
- how to get the list of command that need to be executed to build a target?
How do I create an EDE project type with the following capabilities:
- key file is Makefile in folder BUILD (BUILD may be anywhere, but
contains a top-level Makefile)
- there is a default target in the Makefile called TARGET
- TARGET depends (described properly in the Makefile) on a set of C++
headers and sources, all of them use the same compiler settings (wrt.
defines and include paths)
- how do I specify include folders and defines in the project type?
- how do I create an instance of this project type?
- how do I add source files to an instance of this project type?