<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 8, 2020 at 4:59 PM Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 9/10/20 8:24 am, Joel Sherrill wrote:<br>
> Hi<br>
> <br>
> I am not sure if this is avoidable but it is surprising. <br>
> <br>
> + build and install rtems to $prefix<br>
> <br>
> + build and install libbsd to $prefix<br>
> <br>
> + ./waf will then rebuild some files. It appears to be using installed headers<br>
<br>
Is this in rtems or libbsd?<br></blockquote><div><br></div><div>libbsd. RTEMS can be install and then "./waf" does nothing like you would expect. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> + Then ./waf install and it will also rebuild some files before fails.<br>
<br>
Again which or is it both? <br></blockquote><div><br></div><div>libbsd only </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> I think there is no way to avoid this and waf for libbsd should detect that it<br>
> sees headers installed from itself and give an error that you need a clean<br>
> $prefix to build.<br>
<br>
Waf uses an md5 checksum for dependency checking so replacing a file with the<br>
same file should not trigger a rebuild, the contents have to have changed. This<br>
is different to make and others that stat a file.<br></blockquote><div><br></div><div>Then something is confusing it. The first build is with the file in the libbsd tree. Running</div><div>waf again, I think it is using the installed one.  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> Just to make sure there wasn't interference between two different BSPs, I built<br>
> and installed one followed by a second different one. That went fine. <br>
> <br>
> The behavior is bizarre and the weird compilation errors are mysterious until<br>
> you repeat the steps enough to figure it out. Unless someone knows how the build<br>
> can avoid this, I think we need an error check early in the configure process. <br>
<br>
This implies some files in one package are overwriting a file installed by<br>
another package. That should not happen.<br>
<br>
It would be nice to install a manifesto of the files a package installs. I am<br>
sure it would aid deployment for those wanting to package and deploy RTEMS with<br>
rpm, deb or what ever else. It would help here as the contents of each could be<br>
reviewed.<br></blockquote><div>It would be nice but I don't think that solves this. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> I think it is sufficient to check if machine/rtems-bsd-nexus-bus.h is installed<br>
> already ad give a nice explanation and failure during configure.<br>
<br>
Adding this would limit those develop and maintaining these packages.<br></blockquote><div><br></div><div>The behavior now seems to confuse in-tree and installed header files is my guess.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> Thoughts?<br>
<br>
Should we understand the interactions before we decide on a solution?<br></blockquote><div><br></div><div>Sure. If there really is an avoidable bug. </div><div><br></div><div>--joel</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Chris<br>
</blockquote></div></div>