Re: [CEDET-devel] error: Attempt to load an unsafe project (bug elsewhere in EDE)

[Eric M. L. <er...@si...>]

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.

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.

Eric