View topic - Include file change does not cause re-build all

Search

Include file change does not cause re-build all

AVR Freaks Forum Index » AVR (8-bit) Technical Forums » AVR Studio 5 and Atmel Studio 6 forum

Author

Message

nathangw

Posted: Jun 13, 2012 - 06:14 PM

Joined: Oct 15, 2004
Posts: 2
Location: USA

I’m new to Atmel Studio 6. I have a simple question.
When I change a #defined value in sam3s_ek.h, it doesn’t cause an automatic re-compile of all the .c files that include this file. I have to manually hit REBUILD SOLUTION whenever I make a change to the .h file. This is rather annoying.
Do most people have to use the rebuild solution button very often? I didn’t have this problem on IAR, because the IDE was smart enough to re-build on it’s own.

clawson

Posted: Jun 13, 2012 - 06:20 PM

Joined: Jul 18, 2005
Posts: 62220
Location: (using avr-gcc in) Finchingfield, Essex, England

The Makefile is supposed to have rules to create .d files on the first build so that a tree of #include's is made. On subsequent builds these .d files are scanned for dependencies - maybe this mechanism is broken in AS6 but the underlying mechanism in avr-gcc most definitely works.

EDIT: actually I just checked the simplest of AVR8 projects that has a single #include and note that in the build directory there was this:

Code:

C:\Documents and Settings\asl\My Documents\Atmel Studio\GccApplication1\GccApplication1\Debug>type makedep.mk

################################################################################

# Automatically-generated file. Do not edit or delete the file

################################################################################

GccApplication1.c

that does seem curious as it only lists the source but not the include's?

Further the Makefile seems a little confused:

Code:

C_DEPS +=  \

GccApplication1.d

C_DEPS_AS_ARGS +=  \

GccApplication1.d

OUTPUT_FILE_DEP:= ./makedep.mk

It defines those things but I don't see them being used?

Meanwhile this is a build in AS4:

Code:

avr-gcc  -mmcu=atmega16 -Wall -gdwarf-2 -std=gnu99 --save-temps -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT test.o -MF dep/test.o.d  -c  ../test.c

Those -MD -MP -MT -MF are involved in the creation of the .d files and I find files such as this created:

Code:

E:\avr\default\dep>type test.o.d

test.o: ../test.c \

  e:\winavr-20100110\bin\../lib/gcc/avr/4.3.3/include/stddef.h \

  e:/winavr-20100110/lib/gcc/../../avr/include/avr/io.h \

  e:/winavr-20100110/lib/gcc/../../avr/include/avr/sfr_defs.h \

  e:/winavr-20100110/lib/gcc/../../avr/include/inttypes.h \

  e:/winavr-20100110/lib/gcc/../../avr/include/stdint.h \

  e:/winavr-20100110/lib/gcc/../../avr/include/avr/iom16.h \

  e:/winavr-20100110/lib/gcc/../../avr/include/avr/portpins.h \

  e:/winavr-20100110/lib/gcc/../../avr/include/avr/common.h \

  e:/winavr-20100110/lib/gcc/../../avr/include/avr/version.h \

  e:/winavr-20100110/lib/gcc/../../avr/include/avr/fuse.h \

  e:/winavr-20100110/lib/gcc/../../avr/include/avr/lock.h

e:\winavr-20100110\bin\../lib/gcc/avr/4.3.3/include/stddef.h:

e:/winavr-20100110/lib/gcc/../../avr/include/avr/io.h:

e:/winavr-20100110/lib/gcc/../../avr/include/avr/sfr_defs.h:

e:/winavr-20100110/lib/gcc/../../avr/include/inttypes.h:

e:/winavr-20100110/lib/gcc/../../avr/include/stdint.h:

e:/winavr-20100110/lib/gcc/../../avr/include/avr/iom16.h:

e:/winavr-20100110/lib/gcc/../../avr/include/avr/portpins.h:

e:/winavr-20100110/lib/gcc/../../avr/include/avr/common.h:

e:/winavr-20100110/lib/gcc/../../avr/include/avr/version.h:

e:/winavr-20100110/lib/gcc/../../avr/include/avr/fuse.h:

e:/winavr-20100110/lib/gcc/../../avr/include/avr/lock.h:

So, yeah, I'd say the dependency generation looks like it is broken.

_________________

larryvc

Posted: Jun 13, 2012 - 07:53 PM

Joined: Dec 06, 2007
Posts: 2512
Location: Redmond, WA USA

Cliff, What was your "simplest of AVR8 projects"? Can you export it so that I can test it here?

I created one and got a perfect .d file like the test.o.d file you posted.

I cannot duplicate the problem the OP is having.

_________________
Larry

Those afraid to embrace the future will quickly fade into the past. - larryvc

nathangw

Posted: Jun 13, 2012 - 07:57 PM

Joined: Oct 15, 2004
Posts: 2
Location: USA

Thanks for leading me to the make files. It appears that the project should be re-built every time a change is made. The exception might be when editing c source files. But, the include files don’t appear to be checked at all unless a re-build all is exicuted.

This is from the AS6 help file. “If you need to rebuild your project after a change to the source files, press Ctrl+Alt+F7.”

Can anybody confirm that it is good practice to always re-build the ENTIRE SOLUTION every time a change is made to an include file? This could take some serious computer power on 100KLoc code project.

clawson

Posted: Jun 13, 2012 - 08:05 PM

Joined: Jul 18, 2005
Posts: 62220
Location: (using avr-gcc in) Finchingfield, Essex, England

Quote:

Cliff, What was your "simplest of AVR8 projects"? Can you export it so that I can test it here?

Simply:

Code:

#include <avr/io.h>

int main(void) {

}

as that includes <avr/io.h> which in turn includes things like <avr/sfr_defs.h>, <avr/fuse.h> and so on I would expect, after building that it would have created a set of dependencies based on all those (and the other nested includes) then if I simply use [Build] normally it should not do anything but if I edit avr/io.h or one of those other headers then [Build] that should force the C file to be rebuilt as it is dependent on the .h

EDIT and now I try it again of course it works as expected. This is like when the man comes out to fix your TV and it just works(*)

(*) actually that analogy is a bit dated because (a) it would cost an arm and a leg to have someone come for a home visit in this day and age and (b) in this throw away society if your TV breaks down you throw it away and buy a new one anyway.

_________________

larryvc

Posted: Jun 13, 2012 - 08:16 PM

Joined: Dec 06, 2007
Posts: 2512
Location: Redmond, WA USA

clawson wrote:

EDIT and now I try it again of course it works as expected.

FM*

* Not Frequency Modulation

_________________
Larry

Those afraid to embrace the future will quickly fade into the past. - larryvc

meslomp

Posted: Jun 21, 2012 - 02:01 PM

Joined: May 02, 2007
Posts: 3007
Location: Nieuwegein, Netherlands

Today a colleague was fighting the same problem.
Is this reported to Atmel already, or is this not an Atmel development issue?

Is this also a problem when working with the AVR8 bit controllers, or only the ARM devices?

regards

_________________
1)Datasheet and application notes checked?
2)tutorial forum
3)Newbie start here

JohanEkdahl

Posted: Jun 21, 2012 - 02:23 PM

Joined: Mar 27, 2002
Posts: 18520
Location: Lund, Sweden

Quote:

Is this also a problem when working with the AVR8 bit controllers, or only the ARM devices?

Cliffs experiment above seems to indicate that it holds for the 8-bit avr-gcc toolchain also.

OT:

Cliff wrote:

So, yeah, I'd say the dependency generation looks like it is broken.

Which once again makes you wonder why Atmel necessarily has to set up a team to build their own avr-gcc tool chain, instead of sponsoring the WinAVR effort. The latter got that stuff right years ago.

The fact that some of the core avr-gcc and/or WinAVR people is or has been "closely affiliated" with Atmel does not make this less perplexing.

It passes the "duck test" for N.I.H.

I'll shut up now..

clawson

Posted: Jun 21, 2012 - 02:26 PM

Joined: Jul 18, 2005
Posts: 62220
Location: (using avr-gcc in) Finchingfield, Essex, England

Don't forget my edit (relating to the 8bit avr-gcc)...

Quote:

EDIT and now I try it again of course it works as expected.

So, no I'm not entirely convinced there's a fault here - maybe just usage error? But what I do recommend is that folks look to see if .d files are being created.

It's also very important which entry on the Build menu you actually use. In AS4 I was just used to use the top entry "Build" each time. Do not be tempted to use the top entry "Build Solution" on the AS6 menu - it is not the same thing.

In AS6 my current default project is named GccApllication1. If I use "Build GccApplication1" - the top entry beneath the 1st divider - it builds everything - if I use it a second time it builds nothing - if I now got to "Dependencies" under the project tree and edit a space into a comment in a system header file such as sfr_defs.h and the "Build GccApplication1" then this time my project .c file is recompiled.

So, yes, it is dependent on the headers and works as expected as far as I can see.

EDIT by the way when I check the "Debug" output directory where my files are being built I find:

Code:

C:\Documents and Settings\asl\My Documents\Atmel Studio\GccApplication1\GccApplication1\Debug>type GccApplication1.d

GccApplication1.d GccApplication1.o: .././GccApplication1.c \

 c:\program\ files\atmel\atmel\ studio\ 6.0\extensions\atmel\avrgcc\3.4.0.65\avrtoolchain\bin\../lib/gcc/avr/4.6.2/../..

/../../avr/include/avr/io.h \

 c:\program\ files\atmel\atmel\ studio\ 6.0\extensions\atmel\avrgcc\3.4.0.65\avrtoolchain\bin\../lib/gcc/avr/4.6.2/../..

/../../avr/include/avr/sfr_defs.h \

 c:\program\ files\atmel\atmel\ studio\ 6.0\extensions\atmel\avrgcc\3.4.0.65\avrtoolchain\bin\../lib/gcc/avr/4.6.2/../..

/../../avr/include/inttypes.h \

 c:\program\ files\atmel\atmel\ studio\ 6.0\extensions\atmel\avrgcc\3.4.0.65\avrtoolchain\bin\../lib/gcc/avr/4.6.2/inclu

de/stdint.h \

 c:\program\ files\atmel\atmel\ studio\ 6.0\extensions\atmel\avrgcc\3.4.0.65\avrtoolchain\bin\../lib/gcc/avr/4.6.2/../..

/../../avr/include/stdint.h \

 c:\program\ files\atmel\atmel\ studio\ 6.0\extensions\atmel\avrgcc\3.4.0.65\avrtoolchain\bin\../lib/gcc/avr/4.6.2/../..

/../../avr/include/avr/iom16.h \

 c:\program\ files\atmel\atmel\ studio\ 6.0\extensions\atmel\avrgcc\3.4.0.65\avrtoolchain\bin\../lib/gcc/avr/4.6.2/../..

/../../avr/include/avr/portpins.h \

 c:\program\ files\atmel\atmel\ studio\ 6.0\extensions\atmel\avrgcc\3.4.0.65\avrtoolchain\bin\../lib/gcc/avr/4.6.2/../..

/../../avr/include/avr/common.h \

 c:\program\ files\atmel\atmel\ studio\ 6.0\extensions\atmel\avrgcc\3.4.0.65\avrtoolchain\bin\../lib/gcc/avr/4.6.2/../..

/../../avr/include/avr/version.h \

 c:\program\ files\atmel\atmel\ studio\ 6.0\extensions\atmel\avrgcc\3.4.0.65\avrtoolchain\bin\../lib/gcc/avr/4.6.2/../..

/../../avr/include/avr/fuse.h \

 c:\program\ files\atmel\atmel\ studio\ 6.0\extensions\atmel\avrgcc\3.4.0.65\avrtoolchain\bin\../lib/gcc/avr/4.6.2/../..

/../../avr/include/avr/lock.h

c:\program\ files\atmel\atmel\ studio\ 6.0\extensions\atmel\avrgcc\3.4.0.65\avrtoolchain\bin\../lib/gcc/avr/4.6.2/../../

../../avr/include/avr/io.h:

c:\program\ files\atmel\atmel\ studio\ 6.0\extensions\atmel\avrgcc\3.4.0.65\avrtoolchain\bin\../lib/gcc/avr/4.6.2/../../

../../avr/include/avr/sfr_defs.h:

c:\program\ files\atmel\atmel\ studio\ 6.0\extensions\atmel\avrgcc\3.4.0.65\avrtoolchain\bin\../lib/gcc/avr/4.6.2/../../

../../avr/include/inttypes.h:

c:\program\ files\atmel\atmel\ studio\ 6.0\extensions\atmel\avrgcc\3.4.0.65\avrtoolchain\bin\../lib/gcc/avr/4.6.2/includ

e/stdint.h:

c:\program\ files\atmel\atmel\ studio\ 6.0\extensions\atmel\avrgcc\3.4.0.65\avrtoolchain\bin\../lib/gcc/avr/4.6.2/../../

../../avr/include/stdint.h:

c:\program\ files\atmel\atmel\ studio\ 6.0\extensions\atmel\avrgcc\3.4.0.65\avrtoolchain\bin\../lib/gcc/avr/4.6.2/../../

../../avr/include/avr/iom16.h:

c:\program\ files\atmel\atmel\ studio\ 6.0\extensions\atmel\avrgcc\3.4.0.65\avrtoolchain\bin\../lib/gcc/avr/4.6.2/../../

../../avr/include/avr/portpins.h:

c:\program\ files\atmel\atmel\ studio\ 6.0\extensions\atmel\avrgcc\3.4.0.65\avrtoolchain\bin\../lib/gcc/avr/4.6.2/../../

../../avr/include/avr/common.h:

c:\program\ files\atmel\atmel\ studio\ 6.0\extensions\atmel\avrgcc\3.4.0.65\avrtoolchain\bin\../lib/gcc/avr/4.6.2/../../

../../avr/include/avr/version.h:

c:\program\ files\atmel\atmel\ studio\ 6.0\extensions\atmel\avrgcc\3.4.0.65\avrtoolchain\bin\../lib/gcc/avr/4.6.2/../../

../../avr/include/avr/fuse.h:

c:\program\ files\atmel\atmel\ studio\ 6.0\extensions\atmel\avrgcc\3.4.0.65\avrtoolchain\bin\../lib/gcc/avr/4.6.2/../../

../../avr/include/avr/lock.h:

which looks fairly healthy to me.

_________________

tsgd84

Posted: Jun 21, 2012 - 04:15 PM

Joined: Oct 16, 2010
Posts: 138
Location: India

Quote:

Is this also a problem when working with the AVR8 bit controllers, or only the ARM devices?

There seems to be an issue with projects created targeting ARM devices, try the following steps to see if normal build triggers the rebuild when changes are made to *.h files,

1. Enable "Use External MakeFile" from the project properties page (Project -> Properties -> Build -> Use External MakeFile) and configure "<Project_Directory>/Debug/MakeFile" in the text box.
2. Edit the "<Project_Directory>/Debug/MakeFile" and add the option

Code:

-MT"$(@:%.o=%.o)"

to all the targets of compiler.
3. If step 2 is confusing, just ignore that step and search for the text

Code:

-MT"$(@:%.o=%.d)"

in the makefile and add

Code:

-MT"$(@:%.o=%.o)"

adjacent to

Code:

-MT"$(@:%.o=%.d)"

4. Save the MakeFile

Now try editing the header file, trigger a build and check if it performs rebuild automatically.

P.S: If possible PM me the makefile, I'll perform the necessary edits and send you the corrected one.

_________________
Regards,
Deena

clawson

Posted: Jun 21, 2012 - 04:29 PM

Joined: Jul 18, 2005
Posts: 62220
Location: (using avr-gcc in) Finchingfield, Essex, England

Quote:

Enable "Use External MakeFile"

But that moves the problem from Atmel to the person who failed to write the Makefile properly. How could Atmel have any influence over that? Surely what's being discussed in this thread is if you use AS6 as an IDE for AVR, AVR32 or ARM using it's internal ability to create Makefiles does it add the correct rules to those Makefiles to correctly generate and process the .d files? The more I like at it the more I think it does.

_________________

tsgd84

Posted: Jun 21, 2012 - 04:58 PM

Joined: Oct 16, 2010
Posts: 138
Location: India

Quote:

But that moves the problem from Atmel to the person who failed to write the Makefile properly. How could Atmel have any influence over that?

Agreed! But then it has been asked to configure the makefile "<Project_Directory>/Debug/MakeFile" generated by Atmel Studio to be used as external makefile which is influenced by Atmel Smile

Quote:

Surely what's being discussed in this thread is if you use AS6 as an IDE for AVR, AVR32 or ARM using it's internal ability to create Makefiles does it add the correct rules to those Makefiles to correctly generate and process the .d files? The more I like at it the more I think it does

But when I compare the makefile generated by Atmel Studio for AVR/AVR32 vs ARM projects, I see there is additional option passed to gcc compiler in case of AVR/AVR32 projects which is nothing but

Code:

-MT"$(@:%.o=%.o)"

that is missing incase of ARM projects!

Just wanted to check if adding this additional option to arm gcc compiler fixes the issue Smile

_________________
Regards,
Deena

meslomp

Posted: Jun 22, 2012 - 06:35 AM

Joined: May 02, 2007
Posts: 3007
Location: Nieuwegein, Netherlands

well what we tried so far is that we changed a .h file in a project then first manually saved it. Then no new build is started.
I think my colleague even has been waiting for at least 5 minutes to pass in case time stamping was an issue (minutes based iso seconds) that did not help.

Both me and my colleague ( both HW) are not into the 'external makefile' stuff and indeed we where/are very pleased that this should not be needed in AVR Studio.
My colleague also used AS6 for 8 bit development and did not notice a problem there. BUT he was about to start playing with that again yesterday when I left, so I do not know what that outcome was.

_________________
1)Datasheet and application notes checked?
2)tutorial forum
3)Newbie start here

tsgd84

Posted: Jun 22, 2012 - 01:18 PM

Joined: Oct 16, 2010
Posts: 138
Location: India

Quote:

Both me and my colleague ( both HW) are not into the 'external makefile' stuff and indeed we where/are very pleased that this should not be needed in AVR Studio.

Atmel Studio internally uses makefile to run the build.
I have asked to enable the external makefile and configure the makefile generated by Atmel Studio as external makefile, and perform the suggested changes to the makefile to see if it fixes the error you faced.
If the suggested changes fixes the issue, then Atmel would fix them in their new releases. Ofcourse, there is no need to use the external makefile for the projects once the fixes are done from Atmel Studio.

_________________
Regards,
Deena

stevech

Posted: Jun 23, 2012 - 06:00 AM

Joined: Dec 18, 2001
Posts: 4702

I can only say that in my job, if a changed .h fails to cause a recompilation of dependent .c/.cpp, I would waste huge amounts of time chasing my tail.

another reason I don't use public domain tools when there is a lot of money at stake.

JohanEkdahl

Posted: Jun 23, 2012 - 10:11 AM

Joined: Mar 27, 2002
Posts: 18520
Location: Lund, Sweden

Quote:

another reason I don't use public domain tools when there is a lot of money at stake.

Is Atmel Studio in the "public domain"?

tsgd84

Posted: Jun 28, 2012 - 03:44 PM

Joined: Oct 16, 2010
Posts: 138
Location: India

Quote:

When I change a #defined value in sam3s_ek.h, it doesn’t cause an automatic re-compile of all the .c files that include this file. I have to manually hit REBUILD SOLUTION whenever I make a change to the .h file. This is rather annoying.

There is a new update available from the extension manager for ARMGCC which has the fix for this issue.

I followed these instructions to install the update to ARMGCC,

1. Start Atmel Studio with Administrator privilege.
2. Go to "Tools -> Extension Manager..."
3. Select "Available Downloads -> Updates" at left pane.
4. Download and install ARMGCC extension
5. Restart Atmel Studio.

Refer the attached screenshot!

_________________
Regards,
Deena

Jump to:

All times are GMT + 1 Hour

AVR Freaks Forum Index » AVR (8-bit) Technical Forums » AVR Studio 5 and Atmel Studio 6 forum

AVRFreaks.net

Search