Thanks for the giant patch. I don't think I can review the whole thing
in one pass, so I'll make a few observations today, and see where that
I recognize that I didn't write project-am in the most transparent way,
so I apologize in advance for requesting more from you than I put in
See notes below:
On 02/15/2010 08:59 PM, Marco <Bj> Bardelli wrote:
> Hi list,
> I propose a patch to scan custom target-type in Makefile.am, for example:
> # Makefile.am
> plugindir = /path/to/plugins
> plugin_LTLIBRARIES = plug-in
> In this situation ede list `plug-in' in targets and try to guess
> `plug-in.c' as source. This is what automake try to do.
So in Automake parlance, if you wrote:
You can make the second line optional?
This made me wonder two things:
1) if all listed files should be tested for existence.
2) should we check if plug-in_SOURCE exists as empty before guessing this?
I would guess no to both, since EDE is really just a short cut, not a
> Another patch for autoconf-edit.el to allow parsing for AC_MACRO in
> a more flexible way.
Could you be more specific? The purpose of the change was not obvious
to me after a quick read of the patch.
> I tested project-am on two projects. i attach the two makefiles trees,
> ready to be loaded by ede.
Thanks. Examples are always important.
Here are some observations on the patch:
+;; For new version of scan(s) functions in Makefile(s) use semantic.
+ (add-to-list 'load-path "../semantic")
+ (add-to-list 'load-path "../semantic/bovine")
+ ;; load compiled file for semantic-version
+ (require 'semantic "../semantic/semantic.elc")
+ (require 'semantic-el "../semantic/bovine/semantic-el.el")
+ (require 'semantic-find "../semantic/semantic-find.el"))
For this, I have several comments.
1) Those files should all be on the load path based on the EDE project.
and add the new paths to the necessary load path for project-am.
2) Why do you need semantic-el.el? Do you mean semantic-make.el
3) I've wanted to update project-am to use semantic for scanning
purposes for a long time. See below for more
+(defun project-am-scan-for-custom-names ()
+ "Return a list of possible custom names (i.e. plugin,mod).
Why is this called "custom-names"? Below it seems specific to "xxxdir",
not "xxxmod". If Automake has a metaname for this type of variable, you
should use that instead of "custom".
+Assume to be in a Makefile.am, search for xxxdir variables.
+If current Makefile.am include others Makefiles,
+recurse on them.
This now becomes the only part of project-am that recurses to additional
included makefiles. This seems like an issue as some things work and
others don't if your makefiles are split up.
> Please test it.
Here is my dilemma in testing.
I have no automated tests on project-am, only on the auto generated
project files. I've recently started building a custom automake project
that I've done some hand-testing on, but I do not have the time or
inclination to hand test every change against every possible Automake
file for every possible change. This change is large, and covers parts
of Automake that I don't understand.
I have two options. The first is to just trust that this will not
affect any old features, and accept the change.
The second is to build some sort of automated test against the current
(CVS) version of project-am, and then test your patch against it when I
am done so that I can better understand the changes, and be able to deal
with the suggestions you listed on your todo list below.
Naturally, I'd be glad if you could do that for me, since I've got my
hands full trying to fix mailing list bugs and get all the tests running
on various flavors of Emacs right now so I can make a new release.
As for your patch, it is starting down a fresh path with Semantic
mechanism for extracting data from the Makefile. This is what it should
have always done, except Semantic didn't exist when I wrote it.
I'd recommend that step 2 after a having a comprehensive test suite is
to convert makefile-edit to use Semantic. It looks like it might be
easy, then it too could be recursive.
Next, your scanning algorithm above might belong in makefile-edit, since
that happens to include a bunch of scanning features also. I would
guess there is some shared features once they all use Semantic.
I would be ecstatic if you could take on this refactoring project. The
lack of tests on this complex feature has left it fragile to change, and
as automake gets more complex, and as folks need EDE to work on these
projects, this will be a huge win.
> I also try to implement ede-system-include-path for project-am, and i
> propose two way:
> 1) scan configure.ac for PKG_CHECK_MODULES macro or similar, based on
> some customizable variable, that have to cache info for ede (not much extensible)
> 2) scan Makefiles outputed from configure to find _CFLAGS macro or
> directly ` -I' occurrences.
Is it possible to call one of the automake/configure functions and query
for this information?
Sort of like:
make -n targetname
and searching for the -I, but perhaps easier?