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 11:40:14 +0300
On Mon, Aug 15, 2011 at 10:20 PM, Lucas van Dijk <info return1 net> wrote:
Now the configure dialog finally works, there's another issue, this time
with the configure.ac script and/or the Makefile.am. But when I run
./configure, in Anjuta or in terminal, the CFLAGS in the resulting Makefile
won't change, when I run ./configure the following way:
./configure CFLAGS='--mmcu=atmega168 -O1'
Any idea what that could be?
The flags should be set in Makefile. What does your Makefiles (not
Makefile.in or Makefile.am) show as CFLAGS value?
Despite that, please note that CFLAGS is treated as environment
variable. So, someone else setting CFLAGS during make most likely will
override yours, and therefore could interfere with unrelated flags.
I think the correct approach for you would be to set AM_CFLAGS in
configure.ac via normal configure variables handling. For instance,
you can introduce a new configure variable called --with-cpuarch that
would set AM_CFLAGS=--mmcu in configure.ac. This way is much more
streamed-lined and you don't have to worry about flags interference
(such with those -g -O2 default flags). Parsing will also be easier
since there will be no double '='.
By the way, I'm starting to think that using autotools for avr-gcc isn't
really the right option. In the future I also want to add AVR Assembly
support, and I think it won't be easy to use autotools for that, and I've
been thinking for some alternative.
You just have to use it the right way. Makefiles only projects are
very good for "up and running", but very hard to automatically manage
higher project structures consistently because of primitive rules
(i.e. every single person writes makefile projects differently) --
this is fundamentally the reason why there is no consistent
portability framework at makefile-only level - and the reason why
automake exists on top of make.
The only sensible management is sticking to make rules alone (this is
how the makefile-only project manager would work) without any
additional assumptions about the structures (so, no AVR specific
configure dialog, for example).
It certainly doesn't prevent creating AVR makefile-only project
templates later on when we have the makefile-only project manager
ready - just like you explained. However that's where anjuta's support
for 'AVR' ends, since you can't anymore reliably manage it further.
] [Thread Prev