On Sat, Oct 26, 2019 at 2:59 PM Chris Johns <chr...@rtems.org> wrote:
>
> On 25/10/19 7:47 pm, Sebastian Huber wrote:
> > the new build system uses a set of *.ini files to configure the build. They
> > are
> > stored in the build lock file:
> >
> > build/.lock-waf_linux2_build:options = {..., 'rtems_options': 'bsps.ini',
> > ...}
> >
> > I would like to issue a re-configuration if one of the *.ini files changes.
> > It
> > would be nice if someone knows a best-practise recipe for waf to do this.
> >
>
> What about issuing an error saying the configuration has changed, a bit like
> waf
> does if the version of waf has changed? Issuing an error lets the user see if
> something changed they did not expect. If they want this they can then
> reconfigure.
>
> I would think about adding a `reconfigure` target which basically gets the
> configure command line and runs it again. It is in .lock* pickled data.
>
> Chris
Adding on, I don't know of any out-of-the-box support for this feature
to re-run configure. The dependency-tracking is done in the build
context rules, I'm not aware of any dependency-tracking in the
configure object. You could probably checksum the ini files during
configure, and create a build rule for the ini files that would
precede other build objects in the dependency tree that checksums them
again, and at the simplest generate the error/warning mentioned by
Chris if the checksum doesn't match the configure-time one, or at more
complex attempt the suggested 'reconfigure' command.
> _______________________________________________
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
