[cpp plugin] 2.3 reports UP-TO-DATE after compilation error

Old Forum
#1

Hi everyone

Using the cpp plugin, if I clean, then build twice with a compilation error in a cpp, it reports the error both times. Now fix the error, and build Then reintroduce the error and build twice. It reports the error the first time, then reports that all tasks are UP-TO-DATE on the second build.

Here’s my build.gradle

apply plugin: 'eclipse'
apply plugin: 'cpp'
  version = '1.0'
  model {
    toolChains {
        gcc(Gcc) {
        }
    }
    components {
        main(NativeExecutableSpec) {
            sources {
               cpp {
                    source {
                        srcDir "src/main/cpp"
                        include "*.cpp"
                    }
                    exportedHeaders {
                        srcDir "src/main/headers"
                        include "*.h"
                    }
                }
            }
            binaries.all {
                if (toolChain in Gcc) {
                    cppCompiler.args "-std=c++11"
                    if (buildType == buildTypes.debug) {
                        cppCompiler.args "-g"
                    }
                    linker.args "-pthread","-lcurl"
                }
            }
        }
    }
}

and here’s --debug from the final build that thinks it’s up to date

12:57:35.673 [INFO] [org.gradle.BuildLogger] Tasks to be executed: [task ':compileMainExecutableMainCpp', task ':linkMainExecutable', task ':mainExecutable', task ':assemble', task ':check', task ':build']
12:57:35.674 [INFO] [org.gradle.execution.taskgraph.AbstractTaskPlanExecutor] :compileMainExecutableMainCpp (Thread[main,5,main]) started.
12:57:35.675 [LIFECYCLE] [class org.gradle.TaskExecutionLogger] :compileMainExecutableMainCpp
12:57:35.688 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] Starting to execute task ':compileMainExecutableMainCpp'
12:57:35.689 [DEBUG] [org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter] Determining if task ':compileMainExecutableMainCpp' is up-to-date
12:57:35.691 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire exclusive lock on task history cache (/home/keith/workspace/telemetryudp2http/.gradle/2.3/taskArtifacts).
12:57:35.693 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired.
12:57:35.694 [DEBUG] [org.gradle.cache.internal.locklistener.DefaultFileLockContentionHandler] Starting file lock listener thread.
12:57:35.700 [DEBUG] [org.gradle.cache.internal.btree.BTreePersistentIndexedCache] Opening cache taskArtifacts.bin (/home/keith/workspace/telemetryudp2http/.gradle/2.3/taskArtifacts/taskArtifacts.bin)
12:57:35.718 [DEBUG] [org.gradle.cache.internal.btree.BTreePersistentIndexedCache] Opening cache outputFileStates.bin (/home/keith/workspace/telemetryudp2http/.gradle/2.3/taskArtifacts/outputFileStates.bin)
12:57:35.723 [DEBUG] [org.gradle.cache.internal.btree.BTreePersistentIndexedCache] Opening cache fileHashes.bin (/home/keith/workspace/telemetryudp2http/.gradle/2.3/taskArtifacts/fileHashes.bin)
12:57:35.732 [DEBUG] [org.gradle.cache.internal.btree.BTreePersistentIndexedCache] Opening cache fileSnapshots.bin (/home/keith/workspace/telemetryudp2http/.gradle/2.3/taskArtifacts/fileSnapshots.bin)
12:57:35.735 [INFO] [org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter] Skipping task ':compileMainExecutableMainCpp' as it is up-to-date (took 0.045 secs).
12:57:35.736 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] Finished executing task ':compileMainExecutableMainCpp'
12:57:35.736 [LIFECYCLE] [class org.gradle.TaskExecutionLogger] :compileMainExecutableMainCpp UP-TO-DATE

Thanks

Keith

#2

Keith,

What I was able to reproduce was the following:

$ gradle clean build --> success $ gradle build --> up-to-date $ echo “nonsense” > src/main/c/nonsense.c $ gradle build --> failure $ gradle build --> up-to-date

This is definitely a bug, but I was able to reproduce it with every version going back to 1.10 (did not try it for versions beyond that), so it doesn’t look like this is a 2.3 regression, but something that’s been there for a while. I’ll open up a JIRA ticket for it and we’ll take a look at it.