[yocto] externalsrc + sstate why is not compatible?

[Koehler, Yannick]

Ok, will try this...

In our case, we are using CMake for most user space app, and when developing purely app related stuff we can use cmake directly thru command-line or eclipse without actually having a need for yocto.  Yocto in this context only serve to build the final image artefact.  As such, CMake ensure that only the correct files gets generated and use its own build folder as well.  We also get the nice benefit of Live Debug with eclipse using the yocto sdk.

Based on that, the file fetcher copy (if recursive) may be enough for us, even more so when combining with ccache, which we also uses.

--
Yannick Koehler

-----Message d'origine-----
De : Magallon, Marcelo 
Envoyé : 6 décembre 2017 13:46
À : Koehler, Yannick <yannick.koehler at hpe.com>
Cc : Alexander Kanavin <alexander.kanavin at linux.intel.com>; yocto at yoctoproject.org
Objet : Re: [yocto] externalsrc + sstate why is not compatible?

On Wed, Dec 06, 2017 at 10:59:37AM -0600, Koehler, Yannick wrote:
> Ok, will try that.  If that works, I may see if I can alter the file 
> fetcher to use symlinks, not sure if sstate subsystem will like that 
> or not.

That was my idea, but I've never tried it. I'm sure the devil is in the details. If you can elide the copy and simply replace it with a symlink, you'd get faster builds.

> If we do so, and someone change the file in /src/somedir will yocto 
> redo the fetch/unpack pattern to recopy over the original content by 
> itself?

Yes, it does. You change a file, and the fetcher runs again. This means S and B are deleted (if split), do_fetch runs again and S is populated fresh. do_configure and do_compile populate B again.

Once you get that working, people will complain as to why the system is rebuilding everything instead of just the file that changed :-) It might work "as expected" if S = B, and your build system in the module is smart enough to produce the correct dependencies (e.g. cmake or bazel).

Marcelo