Today, I tried to run a building script on sources that were in a mounted NAS directory. During the build, I received a warning saying that one of the cmake generated files had a modification time 13 s in the future. Subsequently the build failed, because a header file could not be found.
Now, this building script has never given me any troubles before, and the header file was exactly where it was supposed to be, so I was quite puzzled by the error. However, when I inspected the cmake generated file with the false timestamp, it turned out to contain the CCX_INCLUDES. This makes me suspect that the timestamp is in fact the cause of the problem, but I do not understand how it can influence the build. Could someone please shed a light on this?
Related
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:
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.
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).
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?
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!
I built a very big project, which had a number of sub-projects, using make command. It took me 3 hours. Then by mistake (without cleaning the previous build) I re-executed the make command for a few minutes and then stopped it.
Have I ruined my previous build? How does make actually work behind the scenes? Are building the object files done in an atomic and safe manner?
Note: I cannot really run any of my binary files to see if they are broken since that's another lengthy process. I just want to know if I am fine or I have to re-run the make and let it finish.
If you want to publish this binary as a production version of your commercial product, then I would not rely on it, always be 100% sure that you are using a successfully built version of a fully saved and committed code base.
On the other hand, I you need this for debugging purposes, then you could use this! why? because the make system overrides the output binary only once if finishes compiling all the object files and only if it detects changes that requires a relink of the binary:
After recompiling whichever object files need it, make decides whether to relink edit. This must be done if the file edit does not exist, or if any of the object files are newer than it. If an object file was just recompiled, it is now newer than edit, so edit is relinked.
From GNU make: How Make Works
So if you haven't changed your code base, the linker will not relink the binary, leaving it as it was created by the successful build.
So I'm trying to adapt a file maker plugin to work on a Mac with xcode. There is code already written and compiled for the plugin but we need to update because a lot of internal changes have been made. I open the project in xcode and hit build and I'm given something like 135 errors saying that these files don't exist (e.g. "error: FMWrapper/FMXExtern.h: No such file or directory"). The issue is I'm looking at these files right now, they certainly exist, it's just that they aren't getting read. I've moved them through the project to nearly every file and I still get the same error. The lines that are causing the errors are as such:
#include "FMWrapper/FMXExtern.h"
And so on...
Any suggestions?
The compiler won't scan your whole hard disk for included files recursively (unless you ask it to -- but don't! :). You need to help it out. Otherwise, your builds would take ages.
One way is to specify the path to these sources using the Xcode build setting HEADER_SEARCH_PATHS or USER_HEADER_SEARCH_PATHS.
So you tell Xcode to add the directory that contains FMWrapper/ to the search paths.
Xcode Build Setting Reference
I've been writing less, and using Codekit to compile locally.
Everything compiles to the correct destination as it should.. but
Every time I save a less file, it creates an empty CSS file in the same location on my hard disk. This happens when Codekit is closed, so it doesn't seem to be an issue with the program itself.
I have no idea what is causing this behaviour, I have no other services running.
thanks
For others that get this problem, it's usually a missing or duplicate semicolon on a property or something simple that causes this particular issue. The hard part is tracking down the specific error, so your best bet is to try a couple of different compilers and hope for an error log that tells you at least which .less file is causing the problem. Try node.js with lessc, less.app, winless or whatever else is available to you on your OS. This is a common issues, so it's worthwhile to have another "backup" compiler handy to debug.
I have been able to Archive on Xcode 4 successfully, but all of a sudden (??), I can't. The build fails with an invalid .pch file. The error is pasted in below (got from a reattempt with -Winvalid-pch, but what seems to be happening from the build log is that the precompiled header is not actually getting precompiled-- it's an iOS app, and goes straight from a CopyPNG step to a .m compile.
Could I have flipped something by accident? Nothing seems odd in my diff of the .pbxproj file.
cc1obj: warning: /Users/myname/Library/Developer/Xcode/DerivedData/Foo-afikuaovoaeqhreaaaakpafseuuv/Build/PrecompiledHeaders/Foo_Prefix-guqixmujoiaaaacwjctfkrztxmbz/Foo_Prefix.pch.gch: created by a different GCC executable
cc1obj: error: /Users/myname/Library/Developer/Xcode/DerivedData/Foo-afikuaovoaeqhreaaaakpafseuuv/Build/PrecompiledHeaders/Foo_Prefix-guqixmujoiaaaacwjctfkrztxmbz/Foo_Prefix.pch: No such file or directory
cc1obj: error: one or more PCH files were found, but they were invalid
The "Precompile Prefix Header" build setting is "Yes" for all configurations. Product->Clean doesn't help. Deleting the cached pch stuff under derived data doesn't fix it. Really seems like the whole "precompile" step is missing.
Another factoid: Enabling the setting "Increase Sharing of Precompiled Headers" DOES let it succeed. But I can find almost no reference to what this flag really does, and I have never used it before. And perhaps reasonably, the precompile step still doesn't show up when this happens.
Have you cleaned and then rebuilt? Product Menu ==> Clean. Cleaning usually solves such problems, effectively instructing Xcode to compile everything, regardless of whether it thinks the previous build of that file is still valid.
If that fails, try wiping out the Derived Data folder for the project, at ~/Library/Developer/Xcode/DerivedData/YourProjectNamexxx where xxx is a uuid-style string.
The approved answer is correct, just a note that it works only in some cases.
I just converted a project into workspace and changed Derived Data Location from default to Workspace-relative. Precompiled headers stopped working immediately and cleaning the old location didn't seem to make any difference. Well of cource, since it was the OLD location!
Workspace relative location seems to located inside folder, where the workspace file (myProject.xcworkspace) was saved. There's now new subfolder DerivedData, which contains folder named by workspace, which contains the familiar stuff.
Index folder contains the PrecompiledHeaders, which contains (finally) the several subfolders. Deleting all of those and recompiling forced precompiling happen.