Thread: [cedet-semantic] ede does not obey my hand-written Makefile.am
Brought to you by:
zappo
From: Nicolai S. <nic...@zm...> - 2010-01-27 20:21:51
|
Hi all, coming from ebrowse, I read greedily through the features of cedet and want to benefit from them. Unfortunately it doesn't seem to be able to understand my Makefile.am. The first point: It cannot deal with subdirectories not containing a Makefile.am: test_SOURCES = test.cc test_dir/test2.cc would assign test.cc to the project in question while test2.cc won't be assigned. The second point is: It doesn't understand targets like noinst_PROGRAMS and lib_LTLIBRARIES. Is there any way to get around those issues? Thank you very much! Wishes Nicolai |
From: Nicolai S. <nic...@zm...> - 2010-01-27 20:38:31
|
Hi all, coming from ebrowse, I read greedily through the features of cedet and want to benefit from them. Unfortunately it doesn't seem to be able to understand my Makefile.am. The first point: It cannot deal with subdirectories not containing a Makefile.am: test_SOURCES = test.cc test_dir/test2.cc would assign test.cc to the project in question while test2.cc won't be assigned. The second point is: It doesn't understand targets like noinst_PROGRAMS and lib_LTLIBRARIES. Is there any way to get around those issues? Thank you very much! Wishes Nicolai |
From: Eric M. L. <er...@si...> - 2010-01-29 03:29:13
|
Hi Nicolai, My Automake expertise is not as good as it once was. Is your example a project available for download somewhere, or could you provide a simplified example? A .tar file would be easiest for me. I don't have a test environment for hand-written Automake files yet, so I would love to get a nice simple multi-directory Automake I could use for an automated test of the many features. Thanks Eric On 01/27/2010 03:10 PM, Nicolai Stange wrote: > Hi all, > > coming from ebrowse, I read greedily through the features of cedet and > want to benefit from them. > > Unfortunately it doesn't seem to be able to understand my Makefile.am. > The first point: It cannot deal with subdirectories not containing a > Makefile.am: > test_SOURCES = test.cc test_dir/test2.cc > would assign test.cc to the project in question while test2.cc won't be > assigned. > > The second point is: It doesn't understand targets like noinst_PROGRAMS > and > lib_LTLIBRARIES. > Is there any way to get around those issues? > > Thank you very much! |
From: Nicolai S. <nic...@zm...> - 2010-01-29 16:01:47
Attachments:
am-project-0.1.tar.gz
|
Hi Eric, at first: A big "Thank you" for dealing with my issues! > My Automake expertise is not as good as it once was. Is your example a > project available for download somewhere, or could you provide a > simplified example? A .tar file would be easiest for me. The problems I encountered are basically that ther're far more possible automake targets than are hardcoded into the ede.el and sources residing in subdirectories are not associated to a target by ede. > I don't have a test environment for hand-written Automake files yet, so > I would love to get a nice simple multi-directory Automake I could use > for an automated test of the many features. I've just written one (attached) that tries to be as minimal as possible while still utilizing many of the mentioned features. Coming from C/C++, unfortunately I'm really not able to write some sophisticated elisp code, it's a little bit hard for an elisp beginner to fix those issues by himself... If I may help you out at some other frontier, please let me know! Wishes Nicolai |
From: Eric M. L. <er...@si...> - 2010-01-30 02:55:12
|
Hi Nicolai, Your toplevel Makefile.am has these lines: ------ SUBDIRS = src DIST_SUBDIRS = examples ------ and in cedet/ede/project-am.el (where the src for the EDE project that will read AutoMakefiles lives) I have a comment in the below code snippet that reads: (csubproj (or ;; If DIST_SUBDIRS doesn't exist, then go for the ;; static list of SUBDIRS. The DIST version should ;; contain SUBDIRS plus extra stuff. (makefile-macro-file-list "DIST_SUBDIRS") (makefile-macro-file-list "SUBDIRS"))) which is based on Automake projects I had encountered in the past. Is it untrue that DIST_SUBDIRS should always contain SUBDIRS, or is your project correct, and this code needs updating? Thanks Eric On 01/29/2010 11:01 AM, Nicolai Stange wrote: > Hi Eric, > at first: A big "Thank you" for dealing with my issues! > >> My Automake expertise is not as good as it once was. Is your example a >> project available for download somewhere, or could you provide a >> simplified example? A .tar file would be easiest for me. > The problems I encountered are basically that ther're far more possible > automake targets than are hardcoded into the ede.el and sources residing > in subdirectories are not associated to a target by ede. > >> I don't have a test environment for hand-written Automake files yet, so >> I would love to get a nice simple multi-directory Automake I could use >> for an automated test of the many features. > I've just written one (attached) that tries to be as minimal as possible > while still utilizing many of the mentioned features. > > Coming from C/C++, unfortunately I'm really not able to write some > sophisticated elisp code, it's a little bit hard for an elisp beginner > to fix those issues by himself... > > If I may help you out at some other frontier, please let me know! > > Wishes > > Nicolai |
From: Nicolai S. <nic...@zm...> - 2010-01-30 11:15:40
|
Hi Eric, > Is it untrue that DIST_SUBDIRS should always contain SUBDIRS, or is your > project correct, and this code needs updating? Maybe this has been true in the past, but the in info manual of the automake version I'm reading (1.11) there' the following statement in section "7.2.1 `SUBDIRS' vs. `DIST_SUBDIRS'": " If `SUBDIRS' is defined conditionally using Automake conditionals, Automake will define `DIST_SUBDIRS' automatically from the possible values of `SUBDIRS' in all conditions." And that the tarball you got and has been made with 'make dist' contains alls directories shows that automake will not define but rather redefine DIST_SUBDIRS, that is append to it. Thanks and best wishes Nicolai |
From: Eric M. L. <er...@si...> - 2010-01-30 12:55:46
|
I've checked in a fix to this issue. It should correctly combine and strip duplicates providing all possible subprojects. I also fixed a naming issue that seemed to have been introduced recently. Eric On 01/30/2010 06:15 AM, Nicolai Stange wrote: > Hi Eric, > >> Is it untrue that DIST_SUBDIRS should always contain SUBDIRS, or is your >> project correct, and this code needs updating? > > Maybe this has been true in the past, but the in info manual of the > automake version I'm reading (1.11) there' the following statement in > section "7.2.1 `SUBDIRS' vs. `DIST_SUBDIRS'": > " If `SUBDIRS' is defined conditionally using Automake conditionals, > Automake will define `DIST_SUBDIRS' automatically from the possible > values of `SUBDIRS' in all conditions." > > And that the tarball you got and has been made with 'make dist' contains > alls directories shows that automake will not define but rather redefine > DIST_SUBDIRS, that is append to it. > > Thanks and best wishes > > |
From: Nicolai S. <nic...@zm...> - 2010-01-31 12:52:16
|
Hi Eric, > I've checked in a fix to this issue. At first thank you, but since I don't know if you're still aware of the other issues, I'll sum them up in short: 1.) There many more targets avaiable in an automake project than ede supports: The primary LTLIBRARIES and prepending the primaries by any target installation dir reference ('foo' in the example) are an example. 2.) Source dependencies containing some path relative to a Makefile.am don't seem to get assigned to it. The exponentiate.c used in the src/Makefile.am is an example: libsimple_la_SOURCES = helpers/exponentiate.c simple.c At least in the CVS version I checked out those issues remain... Eric, I really appreciate your (very fast btw) help and I don't want to look my emails look like "Hi guys, I want this feature, please implement it asap". Unfortunately I misused this mailing list as a feature request tracker, maybe I'd better file two feature requests for the two (not related) issues mentioned above to detangle them and thus improving your clearness? Again, if I can help out, writing some C-code (if elisp can bind to it) or whatever, please let me know! Thank you very much! Wishes Nicolai |
From: Eric M. L. <er...@si...> - 2010-02-05 02:43:42
|
Thanks for the list. I knew there was more, but this sums it up nicely. More answers below. On 01/31/2010 07:29 AM, Nicolai Stange wrote: > Hi Eric, > >> I've checked in a fix to this issue. > At first thank you, but since I don't know if > you're still aware of the other issues, I'll sum > them up in short: > > 1.) There many more targets avaiable in an automake project > than ede supports: The primary LTLIBRARIES and prepending the > primaries by any target installation dir reference ('foo' in the > example) are an example. If I understand this correctly, I suspect the list project-am-type-alist is incomplete? This is on line ~79 in project-am.el. Updating this list requires no Emacs Lisp programming skills to speak of unless there is an entirely new kind of target style. I'm not sure what a "primary LTLIBRARIES" is. Is that like lib_LTLIBRARIES, but some other name? In your first email you claimed lib_LTLIBRARIES and noinst_PROGRAMS were not supported, but they are in the list I mentioned. They just don't directly identify the referenced file correctly. If you use M-x ede-speedbar, you can browse down and find those files. For example, I created a makefile.am like this from your base project: -------- bin_PROGRAMS=base base_SOURCES=Base.cpp subdir/foo.hh -------- and speedbar shows this: <-> am-project 0.1 <-> src <-> simplelib <-> base [+] Base.cpp [+] subdir/foo.hh so it seems to 'work', just fail the last step of associating the foo.hh buffer with the project target. > 2.) Source dependencies containing some path relative to a Makefile.am > don't seem to get assigned to it. The exponentiate.c used in the > src/Makefile.am is an example: > > libsimple_la_SOURCES = helpers/exponentiate.c simple.c > > At least in the CVS version I checked out those issues remain... > > Eric, I really appreciate your (very fast btw) help and I don't want to > look my emails look like "Hi guys, I want this feature, please implement > it asap". Unfortunately I misused this mailing list as a feature request > tracker, maybe I'd better file two feature requests for the two (not > related) issues mentioned above to detangle them and thus improving your > clearness? > > Again, if I can help out, writing some C-code (if elisp can bind to it) > or whatever, please let me know! I do have grand plans for a C++ project to move some of the slow parts of Semantic into a separate process, but I am still playing catch-up with bug fixes. The biggest help I could use right now is some of the little bug fixes for the mailing list, and distribution testing to help get cedet 1.0 done. Eric |
From: Eric M. L. <er...@si...> - 2010-02-05 03:51:14
|
On 01/31/2010 07:29 AM, Nicolai Stange wrote: > > 2.) Source dependencies containing some path relative to a Makefile.am > don't seem to get assigned to it. The exponentiate.c used in the > src/Makefile.am is an example: > > libsimple_la_SOURCES = helpers/exponentiate.c simple.c > I checked in a change tonight to ede.el, and project-am.el which made this work for my simple test case I was quoting earlier. Hopefully this will fix things for your examples. Please let me know how it goes. Eric |