On Thu, Jun 23, 2011 at 00:28, Eric M. Ludlam <ericludlam@...> wrote:
> On 06/15/2011 03:11 AM, kristof.ralovich@... wrote:
> [...]
>
>>
>> Hi Eric,
>>
>> 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
>> those.
>>
>> 1)
>> 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?
>>
>> 2)
>> 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?
>>
>> 3)
>> - how do I create an instance of this project type?
>> - how do I add source files to an instance of this project type?
>
> Hi,
>
> This is somewhat non-trivial to answer concisely, so I will need to lean on
> examples and doc in my answer.
>
> The 'how to parse a Makefile' is part of Semantic. For example, if you
> Open a Makefile in a buffer, and do:
>
> M-: (semantic-fetch-tags)
>
> you get the tag list. All the formatting of the tags and what is in them is
> described in the Semantic manual.
>
> Of course, if you know there is a target called FOO, you can more easily
> open said file, and do:
>
> M-: (semantic-find-tag-by-name "FOO" (current-buffer))
>
> You will find that in a Makefile a rule has 'arguments' since Semantic
> treats it like a function, and those are the dependencies.
>
> To get the text of the rule, you can get the overlay out of the tag
> (semantic-tag-overlay) and then get the buffer text from that location.
>
>
> For EDE, if I understand what you want to do, you never need to "create" one
> of these projects for a particular location. Instead you need to write a
> new EDE project type that will automatically discover and instantiate
> itself.
>
> Of the existing projects, none mix the things you want to do in a simple way
> for me to provide as an example.
>
> If you look in ede-generic.el, that project type has an explicit function
> that will enable the project types (ede-enable-generic-project-types), which
> is how to get EDE to use your project. If you look at the classes
> ede-generic-target and ede-generic-project, those classes and methods of
> them show how to make a class detect a file (like a Makefile) and install
> itself. This includes the methods you need to specify include paths and
> macro tables. The ede-generic-config is extra stuff you may not need to
> worry about.
>
> The generic project type, and many other examples all dynamically mix all
> the srcs into one giant target, so if you want target distinction, you will
> need to do something more explicit and deeply complex, much like what is in
> project-am. I can't help much in this case with a simple email.
>
> Alternately, you may find that if you go into ede-generic, and edit
> ede-generic-setup-configuration method for Makefiles, you could add a little
> code that snoops into the Makefile and derives basic stuff like preprocessor
> symbols and include paths. If it is sufficiently generic, we could add it
> into the project type for others.
>
> Eric
>
>
Hi Eric,
I've managed to spend some time on this over the weekend and get
started a bit with parsing Makefiles with semantic. Now I'm able to
find targets, retrieve the commands associated with a target, and if
it is a c++ compiler command to parse the include paths (-I) and
defines (-D). My progress is very slow as I have to learn everything
about elisp on the go.
But still, this all works very nice unless there are Makefile
variables that are defined in a separate Makefile that is included in
the one I'm parsing. Cmake generates a lot of this like:
[...]
# Include the compile flags for this target's objects.
include pso/io/CMakeFiles/psoio.dir/flags.make
[...]
pso/io/CMakeFiles/psoio.dir/Image.cpp.o: pso/io/CMakeFiles/psoio.dir/flags.make
pso/io/CMakeFiles/psoio.dir/Image.cpp.o: /home/tade/dev/pso/pso/io/Image.cpp
$(CMAKE_COMMAND) -E cmake_progress_report
/home/tade/dev/pso-bin/CMakeFiles $(CMAKE_PROGRESS_1)
@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green
"Building CXX object pso/io/CMakeFiles/psoio.dir/Image.cpp.o"
cd /home/tade/dev/pso-bin/pso/io && /usr/lib/ccache/c++
$(CXX_DEFINES) $(CXX_FLAGS) -o CMakeFiles/psoio.dir/Image.cpp.o -c
/home/tade/dev/pso/pso/io/Image.cpp
[...]
In the above $(CXX_DEFINES) is defined in
pso/io/CMakeFiles/psoio.dir/flags.make.
Is there a way to tell semantic to resolve these variables too? With C
jargon, to preprocess the given Makefile? Basically I'd like to
(semantic-fetch-tags) after the includes are included.
Thanks a lot,
Kristof
|