build keeps compiling a sorce file...

[dfatcb]

Hi,

So all of a sudden the build (of 1000's of files) has one file that keeps wanting to be rebuilt every time I do a build.  This is 10.5 on debian linux, lenny, using a networked FAT32 partition on a server.  I can see the .o file has the time/date it built it (again), I looked at the header and source files and they all have good dates.  I've done a complete rebuild, etc..  But this one guy is stuck... how do I unstick it?

TIA!!

[MortenMacFly]

If the date of that fie on the remote partition is in the future (because the remote's PC clock is not set the same as your PC) this happens. Check the file's date and set it to past of what your local computer's clock is.

[dfatcb]

It's not. it's from 9/30/2012

[MortenMacFly]

It's not. it's from 9/30/2012

The question is not whats the date on the source, but whats the date on the remotely mounted partition?

[Jenna]

Check all dates, also the dates of sources and object-files,

[dfatcb]

The remote windows server date/timezone is correct, the local machine date/timezon is correct, the virutalbox running debian is correct date/timezone.  the mount point in virtual box (/media/sf_foldername) date on that one is 12/31/1979. 

The exact date on the files are:

name.cpp = 9/29/2012 at 11:13am
1 >name.hpp = 1/13/2007 at 1:08pm
2   >/path/name.hpp = 9/29/2012 at 11:13am
3      >common.h = 1/13/207 at 1:08pm
4        >/path/common.h = 10/15/2012 at 5:26pm
5           >gccsup.h = 11/22/2011 at 8:34am
6      >sup.h  = 1/13/2007 at 1:08pm
7        >/path/sup.h = 9/6/2012 at 2:12pm
8          >#3
9      >align2.h = 1/13/2007 at 1:08pm
10       >/path/align2.h = 1/8/2004 at 3:49pm
11     >alignend.h = 1/13/2007 at 1:08pm
12       >/path/alignend.h = 1/8/2004 at 3:50pm
13 >string.h
14 >stdio.h

The object file is:10/26/2012 at 8:00pm (last make)

[dfatcb]

This problem still exists in the latest 12.x version.

Is there a debugging mode I can enable to see why it says it needs to compile the file?

[Jenna]

You can look into the files properties to see which time C::B sees.
Did you try to open the file in C::B and save it ?
Does it include a header which has an incorrect date (probably from outside the project-tree: tird-party lib, compiler, etc.) ?

[dfatcb]

There are two files in the same directory that are being built - both include the same headers.  the problem one is dated 09/11/2012 08:44:28 in properties, the other is 27/09/2012 02:05:26

The format of the date showing above in properties of Code::Blocks is DD/MM/YYYY

The file does it on both the debug and release builds.

From linux the ls-l of the .o files show the problem one with Jan 17 12:42 (because it always builds) and the other one Nov 16 17:18.

Yes, in the past I tried changing the file and saving it, but it didn't fix it that time.  I could try again I guess.

So now the time in C:B is 17/01/2013 12:50:54

Tried to build workspace .. again it showed up expected, build again .. it showed up when it shouldn't have.  It's the only file with a problem, all the other 200+ files are fine.

[dfatcb]

I just found the problem and fixed it ... summary .. The files were located on a network drive on a Windows box, the build was occurring on a Linux Debian installation.   I listed the files in that folder from linux and noticed the problem file was all CAPS.  I noticed the file name in Code::Blocks was all lower case.  So from linux I did a mv on the file to convert it to lower case.  Tried build and it worked, it didn't pick the file up.  To confirm, I changed the file again, built and it built it (so it was finding it), next I built again and it correctly didn't build it.  So there you go, it's a upper/lower case mismatch issue from Code::Blocks in Linux accessing files on a file system where case is not significant.

[Jenna]

How did you get the file into the project ?
Can you try to remove it and add it again (if it does not work correctly) ?
The case should be correct if C::B adds it to the projectfile.

Is it possible, that the case of the file name has changed for some reason after it was added to the project ?

[Jenna]

I tested it with a FAT-formatted USB-stick.
It's not a C::B issue:

Code

jens@fedora-aspire:/run/media/jens/VOLUME/test$ ll
insgesamt 32
drwx------. 3 jens jens 4096 17. Jan 22:20 bin
-rw-r--r--. 1 jens jens  108 17. Jan 22:19 MAIN.CPP
drwx------. 3 jens jens 4096 17. Jan 22:20 obj
-rw-r--r--. 1 jens jens  145 17. Jan 22:22 test.bmarks
-rw-r--r--. 1 jens jens  718 17. Jan 22:22 test_build_log.html
-rw-r--r--. 1 jens jens 1097 17. Jan 22:22 test.cbp
-rw-r--r--. 1 jens jens  167 17. Jan 22:22 test.depend
-rw-r--r--. 1 jens jens  139 17. Jan 22:22 test.layout
jens@fedora-aspire:/run/media/jens/VOLUME/test$ ll main.cpp
-rw-r--r--. 1 jens jens 108 17. Jan 22:19 main.cpp

AS you can see the file is correctly listed as MAIN.CPP by the OS, but explicitely listing igt in lowercase returns the name in lowercase, so it is impossible for C::B (or the underlying wxWidgets) to see that the name has changed (or at least it can not be done easily).

[dfatcb]

yeah, maybe the name changed after it was added to the project? 

Anyway, it all works now that I renamed it.  Not sure why the name change threw it off and made it want to build?

However, this thread may help someone else in the same situation.