Re: [anjuta-devel] autoconf issue, maybe better to create new project backend for AVR plugins (based on a standard makefile)?

I have thought about the same idea a few years ago but Naba was against this options because it means that you have a kind of anjuta project format. Someone using another IDE cannot really work on such project and you cannot use Anjuta to work on a valid makefile project not compliant with this format. I'm agree that it is much easier to write and provide a nice interface for the user. We haven't chosen this solution though.

Then, perhaps we can consider that AVR projects are quite small and collaboration is less important or consider that most of the AVR projects are using these templates and use this solution. But I would prefer to have a solution using a standard makefile even if the most complex cases are not fully supported.

Anyway, I think you still have to hack existing dialogs because all user interface is provided by the project manager and I think it's much better to keep at least this plugin.

I don't fully agree this is a 'sort of anjuta project format', as it's just a normal Makefile, but one Anjuta can understand. It's a bit the same as autotools, only less complex and less stuff AVR programs don't need. There are a lot of other IDE's who also can't handle autotools based projects. Anyone without Anjuta can still work with the project because the Makefile is well documented, and easy to configure.

My most concern in the current solution is parsing the configure string, when the UI changes. To check whether some compiler options are already there and which are not, IMO this is too error prone, and a too hacky solution.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]