On Wed, Nov 2, 2022 at 9:14 AM Joel Sherrill <j...@rtems.org> wrote: > > > > On Wed, Nov 2, 2022 at 10:10 AM Gedare Bloom <ged...@rtems.org> wrote: >> >> On Wed, Nov 2, 2022 at 1:10 AM Christian MAUDERER >> <christian.maude...@embedded-brains.de> wrote: >> > >> > Hello Chris, >> > >> > Am 01.11.22 um 22:08 schrieb Chris Johns: >> > > On 2/11/2022 3:25 am, o...@c-mauderer.de wrote:> Is it a good idea to >> > > make it a >> > > mandatory attribute? It makes the yaml files >> > >> bigger. It will only mean that we have to look for copy and paste bugs >> > >> instead >> > >> of missing attributes if someone adds a new third party library. >> > > >> > > Can you avoid having to add the item to all? I am no spec build system >> > > expert >> > > (having invested time) and seem to remember needing to hit a lot of >> > > files when >> > > adding something ... >> > > >> > > https://git.rtems.org/rtems/commit/?id=6f2aa8ad36e3aaffc9fa2cb8c744b04da7339ee2 >> > > >> > > Chris >> > >> > The documentation mentions at least some optional attributes in the >> > specification files. For example "format" in a build option item or the >> > "do-configure" in a build script item: >> > >> > https://docs.rtems.org/branches/master/eng/req/items.html#build-option-item-type >> > https://docs.rtems.org/branches/master/eng/req/items.html#build-script-item-type >> > >> > But I think the wscript has to take into account that the value might >> > not exist. I'm not sure whether it does that for the existing "optional" >> > attributes. For example my first guess would be that the "do-configure" >> > could throw a KeyError: >> > >> > https://git.rtems.org/rtems/tree/wscript#n1127 >> > >> > def do_configure(self, conf, cic): >> > script = self.data["do-configure"] >> > if script: >> > exec(script) >> > >> > Usually I would have expected the following code instead: >> > >> > def do_configure(self, conf, cic): >> > try: >> > script = self.data["do-configure"] >> > except KeyError: >> > script = None >> > if script: >> > exec(script) >> > >> Thanks for this recommendation and the discussion/example. Indeed, the >> plumbing right now in the wscript is not very robust to optional >> attributes. For this particular third-party attribute I will take a >> stab at making it optional. >> >> I think the additional metadata we would like to track regarding >> third-party sources can be added incrementally or even separately. I >> would like to first solve the problem of how to separate third-party >> from project-owned sources. Once that is done, then we can discuss >> more ways to improve or use this capability. > > > Are you thinking of a more distinct placement of third party sources > in the source tree? like a cpukit/thirdparty/... sub-tree?
No. I would like to support 3rd party sources wherever they are best found, and to keep track of them separately through the build system since it already understands the various files/sources involved. I think this makes the most sense for maintenance in the longer-term. >> >> >> > So I can't clearly answer your question. I would have to try it. But >> > regardless whether there are currently such options or not: They >> > shouldn't be hard to implement. I just hope that this doesn't break some >> > use case. I'll try to remember to ask Sebastian about it next week. >> > >> Thanks, I will appreciate that feedback and any tricky things to watch out >> for. >> >> > Best regards >> > >> > Christian >> > -- >> > -------------------------------------------- >> > embedded brains GmbH >> > Herr Christian MAUDERER >> > Dornierstr. 4 >> > 82178 Puchheim >> > Germany >> > email: christian.maude...@embedded-brains.de >> > phone: +49-89-18 94 741 - 18 >> > mobile: +49-176-152 206 08 >> > >> > Registergericht: Amtsgericht München >> > Registernummer: HRB 157899 >> > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler >> > Unsere Datenschutzerklärung finden Sie hier: >> > https://embedded-brains.de/datenschutzerklaerung/ >> _______________________________________________ >> 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