1

short background info:

For some rather convoluted reasons I am trying to trick my projects build system. We are working with Code Composer Studio on Windows from Texas Instruments and the gmake implementation that was included. We use the standard Debug build option pretty much unmodified as far as I am aware of (my understanding of make and our implementation of it is unfortunately limited). When developing in Code Composer the build works as one would expect, only the files that have been changed and their dependencies are changed. Sometimes I need to regenerate all code from a code generator that we use however, triggering a complete rebuild.

Trying to trick this complete rebuild I wrote a python script that moves all the original files out from the project, waits for the code generator, then compares the files and replaces the new identical files with the old ones. Thus the creation timestamp and the last modified timestamp should be preserved. This also seems to work when examining these properties. However a complete rebuild of the problem is always triggered.

Core of the Problem:

  1. Having already built the project in Code Composer and building again it concludes that nothing has changed and that there is nothing to do, as one would expect.
  2. I move a file out of the folder and back in again, preserving both the creation time stamp and last modified time stamp as far as I can see (in windows explorer -> properties).
  3. When now rebuilding the project it will rebuild the said file and its dependencies, despite it being identical to before and having the same timestamps.

What is gmake looking at? Does it detect that the folder has been changed. Is it looking at some other hidden timestamp? Is it a Windows problem? Shouldn't it be possible to do this, inserting a file with an old timestamp?

What am I missing? Anyone have a clue?

Mange_Man
  • 41
  • 1
  • 6
  • 1
    In Unix, `cp -p` preserves last-modified timestamps; is there an equivalent in Windows? Also, do you know beforehand which files the generator will change, or must you compare the old and new versions? – Beta May 11 '20 at 15:13
  • I mean, there's no way we can tell since we have no idea what the makefile does. All I can assure you is that standard GNU make looks only at the time last modified timestamp on files to determine whether or not something is out of date, it doesn't look at anything else. You say you have a version of GNU make that came with some other tool; maybe they modified GNU make to behave differently? You should have received (or be able to receive on request) the source code for the GNU make program that you got; maybe you can see any patches they applied. – MadScientist May 11 '20 at 16:53
  • 1
    Anyway, the simplest thing to do is invoke GNU make with the `-d` option which will describe (in excruciating detail) all the decisions made in terms of why something is rebuilt... examining that output should tell you why make considers targets out of date. – MadScientist May 11 '20 at 16:54
  • I should point out when I say _on files_ above I mean both files and directories. That is, if your target lists a directory as a prerequisite and the directory is changed, the target will rebuild. It's virtually never a good idea for a target to depend on a directory because the modification timestamps on directories are maybe not what you'd expect. – MadScientist May 11 '20 at 16:56
  • @Beta all files get regenerated regardless, which is unfortunate. MadScientist I will try examining further with the -d flag – Mange_Man May 12 '20 at 07:06
  • Yes, I understand that all the files are regenerated, but do you know beforehand which ones will be *different after regeneration?* – Beta May 12 '20 at 15:42
  • @Beta yes as long as I am the one making changes (which is rougly 70 % of the time) I know which files are being changed. But only in my head so to speak, I am not aware of any good way in which to get that information digitally on the computer in scriptable form, other than me entering it manually. – Mange_Man May 15 '20 at 08:05
  • working with the debug option proposed by @MadScientist I think I have isolated the problem. Will update shortly. – Mange_Man May 15 '20 at 08:07
  • 1
    How do you move your file out @Mange_Man? [Windows Explorer doesn't preserve the file properties like you seem to believe](https://superuser.com/questions/146125/how-to-preserve-file-attributes-when-one-copies-files-in-windows). – Chnossos May 18 '20 at 14:35
  • @Chnossos. I don't believe the question you linked can be directly applied to this case. I did experiment with copying first and in that case the creation timestamp is renewed to the time of the copy. The directory modification timestamp is not of interest in this case. Currently I move the files, scriptwise with python utils and manually by dragging and dropping. In both case both the creation timestamp and modification timestamp is unchanged as far as I can tell. See case 3 in my answer. But I appreciate the input and I could be mistaken – Mange_Man May 19 '20 at 07:22

1 Answers1

1

Having examined this I concluded that the problem does not lie with gmake or the makefile but with Code Composer Studio's/Eclipse makefile generation.

We use the built in makefile generation in Code Composer Studio (which is an Eclipse derivative). It seems to keep track of if files have been removed/moved out from the projects workspace. If it has it removes the dependecies of that files during the makefile generation, triggering a rebuild.

Examples:

Case 1, works as I expect:

Rebuilding an unchanged project in Code Composer Studio. Nothing is recompiled since nothing is changed.

Case 2, works as I expect:

Changing something in a single then rebuilding results in recompilation of only that single file. As I/once expects.

Case 3, does not work as I expect:

Having an unchanged project and the moving one source code file (xyz.cpp) out of the project, not changing it in any way and then mvoing it back results in a recompilation of xyz.obj.

Code Composer/Eclipse seem to keep track on the filestructure. Despite the file being put back into the project exactly the way it was, Code Composer/Eclipse deletes xyz.obj during the makefile generation, triggering a rebuild. On the other hand; closing Code Composer, moving the file back and forth, Reopening Code Composer and regenerating makefile/rebuilding works as one expects. Nothing is rebuilt and no .obj files are removed.

Since this didn't have anything to do with gmake and makefile I guess this question was invalid/unrelevant to begin with. I will collect my thoughts and reformulate a new question formulated strictly as a Code Composer/Eclipse errand.

If anyone has found themselves in the same situation or have relevant information on their hands please share however!

Mange_Man
  • 41
  • 1
  • 6