CEDET

Hi,

Don't I use ede the way it is designed to function or is there
something incomplete in the code but I encounter following
problem :

ede seems to be confused when two targets have the same name in
two different projects or subprojects of a given project. 

Precisely imagine you have two directories proj1 and proj2
containing Project.ede files and files associatted to
targets. Imagine that there is a target.elc target in each
project proj1 and proj2. (I don't think that such a situation
is so exotic that it may never occur !) 

When looking for target.elc parent (with ede-target-parent
method) ede will try to knàow if target.elc belongs to any
project simply examining the ede-projects variable. Anyway
since the the target.elc seems only be characterized by its
name it might belong as well to proj1 and proj2 and the first
in the list will be the one ! But then trying to resolve the
path the process wil crash.

My opinion is that a target should kepp track more closely of
the project from which it depends. Why not have a slot kepping
the project which might be initialized when project is loaded
or target is created ? I might avoid this dangerous project
fatherhood research ... 

Once more :

1. If I am completely wrong and do not understand anything
simply tell me ! 

2. If there is really something to do but none have time to do
it simply tell me as well I might perhaps find a few seconds to
do ti (who knows ?) 

Regards

Pierre

Re: [CEDET-devel] ede targets From: Eric M. Ludlam <eric@si...> - 2007-08-25 14:52 Hi, A bug like that has bitten me on occasion, but I was usually busy trying to get something else done. I finally looked into it today, and found that the code that identifies if a target is in a project used equal, instead of eq. I changed that, and my version of the bug was fixed. If I understand your problem, your dilemma seems to revolve around the idea that in EDE, a source file can belong to only one target. I'm not sure sure of this guess. If you could download the latest ede.el from CVS which fixes my bug (which I described above) and try again to see if it is resolved or not. If not, and the bug you describe throws an error, a good step is to do this: M-x toggle-debug-on-error RET and then repro the problem. Often the stack is enough for me to fix a bug. Good Luck Eric >>> Pierre Lorenzon <pollock.nageoire@...> seems to think that: > > >Hi, > >Don't I use ede the way it is designed to function or is there >something incomplete in the code but I encounter following >problem : > >ede seems to be confused when two targets have the same name in >two different projects or subprojects of a given project. > >Precisely imagine you have two directories proj1 and proj2 >containing Project.ede files and files associatted to >targets. Imagine that there is a target.elc target in each >project proj1 and proj2. (I don't think that such a situation >is so exotic that it may never occur !) > >When looking for target.elc parent (with ede-target-parent >method) ede will try to knàow if target.elc belongs to any >project simply examining the ede-projects variable. Anyway >since the the target.elc seems only be characterized by its >name it might belong as well to proj1 and proj2 and the first >in the list will be the one ! But then trying to resolve the >path the process wil crash. > >My opinion is that a target should kepp track more closely of >the project from which it depends. Why not have a slot kepping >the project which might be initialized when project is loaded >or target is created ? I might avoid this dangerous project >fatherhood research ... > >Once more : > >1. If I am completely wrong and do not understand anything >simply tell me ! > >2. If there is really something to do but none have time to do >it simply tell me as well I might perhaps find a few seconds to >do ti (who knows ?) > >Regards > >Pierre > > >------------------------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. >Still grepping through log files to find problems? Stop. >Now Search log events and configuration files using AJAX and a browser. >Download your FREE copy of Splunk now >> http://get.splunk.com/ >_______________________________________________ >Cedet-devel mailing list >Cedet-devel@... >https://lists.sourceforge.net/lists/listinfo/cedet-devel > -- Eric Ludlam: zappo@..., eric@... Home: http://www.ludlam.net Siege: http://www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org

Re: [CEDET-devel] ede targets From: Pierre Lorenzon <pollock.nageoire@wa...> - 2007-08-27 04:55 Hi Eric, I downloaded the last cvs version and it seems to solve the bug I mentioned : indeed using memq instead of member seems to be a good idea ! But now another bug seems to appear ! You modified implementation of the ede-parent-project method at line 1494 of ede.el file. Sure, argument obj is optional in this method hence you might call it without any argument at line 854 in the ede-new method. However your new implementation of ede-parent-project method calls ede-project-root unconditionally on obj (at line 1498) and if obj is nil it produces an error since this generic method might not be called without any argument ! What should we do ? Regards Pierre > I finally looked into it today, and found that the code that > identifies if a target is in a project used equal, instead of eq. I > changed that, and my version of the bug was fixed. OK ! > > If I understand your problem, your dilemma seems to revolve around > the idea that in EDE, a source file can belong to only one > target. ½Not exactely : the probelm is not that a source file has to belong to one or more targets but that two different soucre files have the same name (without the directory part) and that caused the bug I mentioned : anyway it is solved by testing if objects are really eq and only their content is equal ! > > I'm not sure sure of this guess. If you could download the latest > ede.el from CVS which fixes my bug (which I described above) and try > again to see if it is resolved or not. Yes it solves the bug ; but as I said above a new problem has appered ... > > If not, and the bug you describe throws an error, a good step is to > do this: > > M-x toggle-debug-on-error RET debug-on-error is always on in my emacs when I am developping something ! Regards Pierre

Re: [CEDET-devel] ede targets From: Eric M. Ludlam <eric@si...> - 2007-08-27 10:08 Hi, Good find. I checked in a change that makes sure there is an object passed in before looking to see of the object knows where its root is. Thanks Eric >>> Pierre Lorenzon <pollock.nageoire@...> seems to think that: > >Hi Eric, > >I downloaded the last cvs version and it seems to solve the bug >I mentioned : indeed using memq instead of member seems to be a >good idea ! > >But now another bug seems to appear ! You modified >implementation of the ede-parent-project method at line 1494 >of ede.el file. Sure, argument obj is optional in this method >hence you might call it without any argument at line 854 in >the ede-new method. However your new implementation of >ede-parent-project method calls ede-project-root >unconditionally on obj (at line 1498) and if obj is nil it >produces an error since this generic method might not be called >without any argument ! > >What should we do ? > >Regards > >Pierre > >> I finally looked into it today, and found that the code that >> identifies if a target is in a project used equal, instead of eq. I >> changed that, and my version of the bug was fixed. > > OK ! > >> >> If I understand your problem, your dilemma seems to revolve around >> the idea that in EDE, a source file can belong to only one >> target. > >½Not exactely : the probelm is not that a source file has to >belong to one or more targets but that two different soucre >files have the same name (without the directory part) and that >caused the bug I mentioned : anyway it is solved by testing if >objects are really eq and only their content is equal ! > > >> >> I'm not sure sure of this guess. If you could download the latest >> ede.el from CVS which fixes my bug (which I described above) and try >> again to see if it is resolved or not. > > Yes it solves the bug ; but as I said above a new problem has > appered ... > > > >> >> If not, and the bug you describe throws an error, a good step is to >> do this: >> >> M-x toggle-debug-on-error RET > > debug-on-error is always on in my emacs when I am developping > something ! > > Regards > >Pierre > -- Eric Ludlam: zappo@..., eric@... Home: http://www.ludlam.net Siege: http://www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org

1 message has been excluded from this view by a project administrator.