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