Module needs rebuild, but isn't rebuild ?

[tboegi]

The problem: I want to test different asyn versions (one version with 64 integer support, one without). Because asyn is changed, motor must be rebuild, but that doesn't seem to happen.

https://api.travis-ci.com/v3/job/353473004/log.txt

BASE 7.0 from cache b8f0fd4 Make BKPT field an epicsUInt8 for consistency ASYN master rebuilt 8573487 Remove SSCAN dependency, it is not needed for building library, only for testEpicsApp application CALC R3-7-3 rebuilt 2a3ceff update gitignore MOTOR ess-master rebuilt b64af24 .SPAM field: Initialize it in motorRecord.dbd

As a result, the cached motor module is loaded, which had been build against an incompatible asyn version, and the IOC core dumps.

This leads to a more general question, how do we organize the directories, when different "sets" are used ? If I have 2 sets, like "asyn_latest" and "asyn_R4_33", then I need to have 2 different directories for motor, even if both are build from the same source (ess-master in my case). One solution could be to have erverything under "asyn_latest/" and "asyn_R4_33", like asyn_latest/asyn, asyn_latest/motor,asyn_latest/calc.

What do you think ?

[ralphlange]

MOTOR ess-master rebuilt b64af24 .SPAM field: Initialize it in motorRecord.dbd shows that the MOTOR module has been rebuilt (3rd column). Only BASE has been taken from cache.

[ralphlange]

Different setups are used in different build jobs, which are not sharing the runner VM, so by definition every job has a separate set of dependency directories.

[ralphlange]

Excerpt from your log file...

First, the checked-out dependencies (loaded from the cache) are checked, and new clones are made for those that are out-of-date:

Found 7.0 of dependency BASE up-to-date in /home/travis/.traviscache/EPICS/base-7.0
Cloning master of dependency ASYN into /home/travis/.traviscache/EPICS/asyn-master
Found R3-7-3 of dependency CALC up-to-date in /home/travis/.traviscache/EPICS/calc-R3-7-3
Found ess-master of dependency MOTOR up-to-date in /home/travis/.traviscache/EPICS/motor-ess-master

Then, starting from the first in the list that was out-of-date, all modules get re-made.

Building dependency ASYN in /home/travis/.traviscache/EPICS/asyn-master
Building dependency CALC in /home/travis/.traviscache/EPICS/calc-R3-7-3
Building dependency MOTOR in /home/travis/.traviscache/EPICS/motor-ess-master

So that the final situation is reported as

Dependency module information
Module     Tag          Binaries    Commit
----------------------------------------------------------------------------------------------------
BASE       7.0          from cache  b8f0fd4 Make BKPT field an epicsUInt8 for consistency
ASYN       master       rebuilt     8573487 Remove SSCAN dependency, it is not needed for building library, only for testEpicsApp application
CALC       R3-7-3       rebuilt     2a3ceff update gitignore
MOTOR      ess-master   rebuilt     b64af24 .SPAM field: Initialize it in motorRecord.dbd

This is exactly what I would expect. Why do you think that the MOTOR module is not being rebuilt?

[tboegi]

Hej Ralph, I have 2 things:

• Iwould expect to see the re-build of the motor to show up in the log file.
• The IOC crash, which typically is an indication (but not a prove) that we have an asyn-mismatch.

How does it work, when the different virtual machines, as you pointed out, share a cache ? I had to change the cache to CACHEDIR=$HOME/.traviscache2/EPICS to get a "clean build". Thanks for the help, (debugging this stuff is hard)

[ralphlange]

To see the re-build of the motor in the log, set the verbosity flag VV=1. (documented.)

[ralphlange]

In the travis web GUI, there is a command to delete the cache. That's what you should have done. (documented.)

[ralphlange]

MOTOR not correctly rebuilding when dependencies have changed might point to dependencies not being tracked properly.

[ralphlange]

If you update ci-scripts to the latest release (3.0.2), you will get a change that runs make clean in the dependency modules. This was introduced on Michael's request to reduce the cache size, but will also have the side effect of doing a complete rebuild of the downstream dependencies (instead of just running make again).

[ralphlange]

There are no shared caches. (That was my point, that I obviously didn't make clear enough.)

The cache key is a hash over the branch and the complete configuration. So only a job that works on the same branch and has exactly the same configuration (compiler, language, all environment variables, ...) will load cached dependencies.

[tboegi]

Thanks @ralphlange ; Point understood, I think. Next week I will spend some time to do more testing; And latest.set has MODULES=asyn calc motor So everything should just work, right ?

[ralphlange]

Ehhhmm... ahem. Yes: Everything should "just work" [TM].

I still wonder why the plain re-build (without clean) of MOTOR doesn't catch the updates in ASYN. I was under the impression that the dependency tracking was able to do that properly. As long as MOTOR sources include header files from ASYN, the updated installed ASYN headers should trigger a rebuild and relink of MOTOR stuff. Is there a place where MOTOR is linking against ASYN without including header files? That would probably be missed by the dependency tracking.

[ralphlange]

Anyway: ci-scripts 3.0.2 with make clean on the dependencies should solve that issue once and for all.

[ralphlange]

Closing as "fixed with 3.0.2"...

[tboegi]

Thanks @ralphlange for the help. After updating to 3.0.2 the problem didn't occur any more