Re: [anjuta-devel] autoconf issue, maybe better to create new project backend for AVR plugins (based on a standard makefile)?
- From: Naba Kumar <naba kumar gmail com>
- To: Lucas van Dijk <info return1 net>
- Cc: anjuta-devel-list gnome org
- Subject: Re: [anjuta-devel] autoconf issue, maybe better to create new project backend for AVR plugins (based on a standard makefile)?
- Date: Tue, 16 Aug 2011 12:13:32 +0300
Hi Lucas,
2011/8/16 Lucas van Dijk <info return1 net>:
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.
I agree, that's true for specific AVR project templates since we are
introducing specific configure variable which is same as introducing
specific make variables. But I don't think there is makefile project
manager ready to even allow you go this approach.
But automake/autoconf for your AVR projects still has other advantages
over Makefile only ones. For one, the modules/sources management,
symbols navigations ... and all the rest of features in Anjuta beyond
just "building" will be available and working nicely. Makefile only
projects will have strong limitations on these features.
There are a lot of other IDE's who also can't handle autotools based projects.
Such IDEs either tend to be very simple to capture least common
denominators - like you can only "make" something, or tend to have
overly custom "Makefile structures" -- making it dangerously
unsuitable to be used outside that specific IDE.
As long those IDEs can deal with Makefile based projects, they will be
usable for any autoconf/automake (anjuta) projects. But if a project
uses autoconf/automake, it's expected that developers of those
projects, no matter what IDE/editor someone uses, rely on
autoconf/automake modifications.
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.
I believe, by sticking to configure variables, like I outlined in
previous email, the parsing issue can be simplified. Even without
that, making a reliable parser that takes into account quotes
shouldn't be that hard. Besides, this hackish approach doesn't really
go way when using Makefile-only approach since you are still needed to
manipulate the flags.
Thanks.
Regards,
-Naba
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]