Eric M Ludlam writes:
> On 02/18/2013 08:55 AM, Lluís wrote:
>> According to this message [1], the error I get protects against the load of
>> 'Project.ede' files, of which I have none.
>>
>> In case it matters, "/project-root/" contains a hand-coded "Makefile", while
>> "/project-root/experiments/" is the root of a hand-coded automake project (i.e.,
>> not generated by EDE).
>>
>> I don't understand why this is considered an unsafe project if there is no
>> "Project.ede" file anywhere in it. BTW, it also looks like the nested automake
>> project is considered as being part of the outer hand-coded makefile project.
>>
>> This is the backtrace I get:
>>
>> Debugger entered--Lisp error: (error "Attempt to load an unsafe project (bug elsewhere in EDE)")
>> signal(error ("Attempt to load an unsafe project (bug elsewhere in EDE)"))
>> error("Attempt to load an unsafe project (bug elsewhere in EDE)")
>> #[(this dir) "..." [this dir o eieio-oref :safe-p ede-directory-safe-p
>> error "Attempt to load an unsafe project (bug elsewhere in EDE)" load-type
>> "Project type error: :load-type failed to create a project"
>> ede-add-project-to-global-list] 4 "Load in the project associated with THIS
>> project autoload description.\nTHIS project description should be valid for
>> DIR, where the project will\nbe loaded."]([object ede-project-autoload
>> "generic-makefile" "Make" ede/generic "Makefile" "" unbound nil
>> ede-generic-load ede-generic-makefile-project t nil nil] "/project-root/")
> That line item is in the "last line of defense" against accidentally loading a
> project that is considered unsafe. That's why it claims it is a bug elsewhere,
> as unsafe projects should have been dodged a while ago.
>> apply(#[(this dir) "..." [this dir o eieio-oref :safe-p
>> ede-directory-safe-p error "Attempt to load an unsafe project (bug elsewhere
>> in EDE)" load-type "Project type error: :load-type failed to create a project"
>> ede-add-project-to-global-list] 4 "Load in the project associated with THIS
>> project autoload description.\nTHIS project description should be valid for
>> DIR, where the project will\nbe loaded."] ([object ede-project-autoload
>> "generic-makefile" "Make" ede/generic "Makefile" "" unbound nil
>> ede-generic-load ede-generic-makefile-project t nil nil] "/project-root/"))
>> ede-auto-load-project([object ede-project-autoload "generic-makefile" "Make" ede/generic "Makefile" "" unbound nil ede-generic-load ede-generic-makefile-project t nil nil] "/project-root/")
> This shows that it is using the "generic makefile" project autoloader. All the
> "generic" project types are unsafe because they might load a configuration save
> file. I didn't have time to add safety checking as a separate entity for
> generic project types, so I just used the generic safety feature instead.
But shouldn't it be unsafe only when actually loading a config file? What I mean
is, shouldn't the check instead be on the routine that actually loads a
Project.ede file?
> If you did "M-x Customize-project" it would allow you to make some changes, and
> save into a .ede file.
> Unfortunately it seems that the loader for projects that aren't being pulled
> directly from a project file doesn't ask the questions needed for you to mark
> the project safe.
> The attached patch just claims it is 'safe', but as the comments notes, we would
> need to add some safety features to the config loader to make this patch worthy
> of being checked in. In the meantime though, it should fix the bug.
In the meantime, I've set `ede-project-directories' to true.
Lluis
--
"And it's much the same thing with knowledge, for whenever you learn
something new, the whole world becomes that much richer."
-- The Princess of Pure Reason, as told by Norton Juster in The Phantom
Tollbooth
|