Re: Typo in rtems-libbsd/rtems_waf/rtems.py?
ok, my "real" problem is that i can't build rtems-libbsd for rtems 5 anymore:
RTEMS_BSP=beatnik
RTEMS_VERSION=5
RTEMS_ROOT=/home/rtems/MVME6100_5_LIBBSD_RUN/rtems/5
RTEMS_ARCH=powerpc-rtems5
rtems@rtems-dev:~/MVME6100_5_LIBBSD_INST$ git clone
https://github.com/RTEMS/rtems-libbsd.git
Cloning into 'rtems-libbsd'...
remote: Enumerating objects: 42896, done.
remote: Counting objects: 100% (2983/2983), done.
remote: Compressing objects: 100% (1006/1006), done.
remote: Total 42896 (delta 1967), reused 2762 (delta 1859), pack-reused 39913
Receiving objects: 100% (42896/42896), 42.95 MiB | 5.47 MiB/s, done.
Resolving deltas: 100% (29323/29323), done.
rtems@rtems-dev:~/MVME6100_5_LIBBSD_INST$ cd rtems-libbsd/
rtems@rtems-dev:~/MVME6100_5_LIBBSD_INST/rtems-libbsd$ git checkout
${RTEMS_VERSION}-freebsd-12
Branch '5-freebsd-12' set up to track remote branch '5-freebsd-12' from
'origin'.
Switched to a new branch '5-freebsd-12'
rtems@rtems-dev:~/MVME6100_5_LIBBSD_INST/rtems-libbsd$ git checkout -b if_mve
de0badf2c3aea5328936e583c842f58e80e56d62
Switched to a new branch 'if_mve'
rtems@rtems-dev:~/MVME6100_5_LIBBSD_INST/rtems-libbsd$ git submodule init
Submodule 'freebsd-org' (https://github.com/freebsd/freebsd.git) registered for
path 'freebsd-org'
Submodule 'rtems_waf' (git://git.rtems.org/rtems_waf.git) registered for path
'rtems_waf'
rtems@rtems-dev:~/MVME6100_5_LIBBSD_INST/rtems-libbsd$ git submodule update
rtems_waf
Cloning into '/home/rtems/MVME6100_5_LIBBSD_INST/rtems-libbsd/rtems_waf'...
Submodule path 'rtems_waf': checked out
'ad08908c452c6a9bbb3bf7bbbcc9fc03fe46cc7f'
rtems@rtems-dev:~/MVME6100_5_LIBBSD_INST/rtems-libbsd$ ./waf configure
--rtems-version=${RTEMS_VERSION} --prefix=${RTEMS_ROOT}
--rtems-bsps=${ARCH}/${RTEMS_BSP} --buildset=buildset/default.ini
Setting top to :
/home/rtems/MVME6100_5_LIBBSD_INST/rtems-libbsd
Setting out to :
/home/rtems/MVME6100_5_LIBBSD_INST/rtems-libbsd/build
RTEMS Version: 5
Architectures: powerpc-rtems5
Board Support Package (BSP) : powerpc-rtems5-beatnik
Show commands: no
Long commands: no
Checking for program 'powerpc-rtems5-gcc' :
/home/rtems/MVME6100_5_LIBBSD_RUN/rtems/5/bin/powerpc-rtems5-gcc
Checking for program 'powerpc-rtems5-g++' :
/home/rtems/MVME6100_5_LIBBSD_RUN/rtems/5/bin/powerpc-rtems5-g++
Checking for program 'powerpc-rtems5-gcc' :
/home/rtems/MVME6100_5_LIBBSD_RUN/rtems/5/bin/powerpc-rtems5-gcc
Checking for program 'powerpc-rtems5-ld' :
/home/rtems/MVME6100_5_LIBBSD_RUN/rtems/5/bin/powerpc-rtems5-ld
Checking for program 'powerpc-rtems5-ar' :
/home/rtems/MVME6100_5_LIBBSD_RUN/rtems/5/bin/powerpc-rtems5-ar
Checking for program 'powerpc-rtems5-nm' :
/home/rtems/MVME6100_5_LIBBSD_RUN/rtems/5/bin/powerpc-rtems5-nm
Checking for program 'powerpc-rtems5-objdump' :
/home/rtems/MVME6100_5_LIBBSD_RUN/rtems/5/bin/powerpc-rtems5-objdump
Checking for program 'powerpc-rtems5-objcopy' :
/home/rtems/MVME6100_5_LIBBSD_RUN/rtems/5/bin/powerpc-rtems5-objcopy
Checking for program 'powerpc-rtems5-readelf' :
/home/rtems/MVME6100_5_LIBBSD_RUN/rtems/5/bin/powerpc-rtems5-readelf
Checking for program 'powerpc-rtems5-strip' :
/home/rtems/MVME6100_5_LIBBSD_RUN/rtems/5/bin/powerpc-rtems5-strip
Checking for program 'powerpc-rtems5-ranlib' :
/home/rtems/MVME6100_5_LIBBSD_RUN/rtems/5/bin/powerpc-rtems5-ranlib
Checking for program 'rtems-ld' :
/home/rtems/MVME6100_5_LIBBSD_RUN/rtems/5/bin/rtems-ld
Checking for program 'rtems-tld' :
/home/rtems/MVME6100_5_LIBBSD_RUN/rtems/5/bin/rtems-tld
Checking for program 'rtems-syms' :
/home/rtems/MVME6100_5_LIBBSD_RUN/rtems/5/bin/rtems-syms
Checking for program 'rtems-bin2c':
/home/rtems/MVME6100_5_LIBBSD_RUN/rtems/5/bin/rtems-bin2c
Checking for program 'tar': /usr/bin/tar
Checking for program 'gcc, cc':
/home/rtems/MVME6100_5_LIBBSD_RUN/rtems/5/bin/powerpc-rtems5-gcc
Checking for program 'ar' :
/home/rtems/MVME6100_5_LIBBSD_RUN/rtems/5/bin/powerpc-rtems5-ar
Checking for program 'g++, c++' :
/home/rtems/MVME6100_5_LIBBSD_RUN/rtems/5/bin/powerpc-rtems5-g++
Checking for program 'ar' :
/home/rtems/MVME6100_5_LIBBSD_RUN/rtems/5/bin/powerpc-rtems5-ar
Checking for program 'gas, gcc' :
/home/rtems/MVME6100_5_LIBBSD_RUN/rtems/5/bin/powerpc-rtems5-gcc
Checking for program 'ar' :
/home/rtems/MVME6100_5_LIBBSD_RUN/rtems/5/bin/powerpc-rtems5-ar
Checking for c flags '-MMD' : yes
Checking for cxx flags '-MMD' : yes
Compiler version (powerpc-rtems5-gcc) : 7.5.0 20191114 (RTEMS 5, RSB
5.not_released, Newlib 7947581)
Checking for a valid RTEMS BSP installation : yes
Checking for RTEMS_DEBUG : no
Checking for RTEMS_MULTIPROC
Re: [PATCH 00/18] Adds Formal Verification Material
Hello, I checked in an updated version of the patch set. You find the new files here: https://github.com/RTEMS/rtems-central/tree/master/formal There is some work in progress to make the test code generation from the model files a bit easier. Once this work is done we could try to add it to the Github workflow. The next step is to continue with the integration of the related documentation into the RTEMS Software Engineering manual: https://lists.rtems.org/pipermail/devel/2022-November/073765.html Kind regards, Sebastian -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 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
Re: [PATCH 1/3] build: Format build items
On 2023-01-17 08:39 +0100, Sebastian Huber wrote: > > The Python modules to work with specification items are in > rtems-central.git. This repository contains also a format specification > of the build items. We could add an action to a Github work flow to > check the build item format for pull requests and commits. I don't chime in here very often but after seeing the recent changes I'm extremely confused. There are now tools that sit outside of the RTEMS repository that now change source files in RTEMS? I have never seen it done this way before. What version of this tool have you used? How can anyone in the future possibly debug this? What should happen here is this tools should sit in the main repository. Any required changes made and then a command run to generate new output: ./waf This lets us know that the output in this commit was generated by code existing in the previous commit. There is no need to version anything it's already done. Having it sitting outside of the source repository makes debugging impossible. Case in point is the commit message here. No explanation as to where these changes have come from. No commit version. I spent a very long time figuring out what was going on and I could not figure it out without digging through the lists. How is anyone in 5, 10, 15 years down the road going to sort through this? What if I want to make a change in 10 years and regenerate. It is impossible as I have no idea what's been done let alone where to look. I'm not against the purpose of the tool or the work has been done but this is not the correct way to handle generated files within a repository if we want to maintain the ability to make changes or debug years down the line. Amar. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/3] build: Format build items
On 19/1/2023 8:58 am, Amar Takhar wrote: > On 2023-01-17 08:39 +0100, Sebastian Huber wrote: > >> >> The Python modules to work with specification items are in >> rtems-central.git. This repository contains also a format specification >> of the build items. We could add an action to a Github work flow to >> check the build item format for pull requests and commits. > > I don't chime in here very often but after seeing the recent changes I'm > extremely confused. > > There are now tools that sit outside of the RTEMS repository that now change > source files in RTEMS? > > I have never seen it done this way before. What version of this tool have > you > used? How can anyone in the future possibly debug this? > > What should happen here is this tools should sit in the main repository. Any > required changes made and then a command run to generate new output: > > ./waf > > This lets us know that the output in this commit was generated by code > existing > in the previous commit. There is no need to version anything it's already > done. > > Having it sitting outside of the source repository makes debugging > impossible. > Case in point is the commit message here. No explanation as to where these > changes have come from. No commit version. I spent a very long time > figuring > out what was going on and I could not figure it out without digging through > the > lists. > > How is anyone in 5, 10, 15 years down the road going to sort through this? > What > if I want to make a change in 10 years and regenerate. It is impossible as I > have no idea what's been done let alone where to look. > > I'm not against the purpose of the tool or the work has been done but this is > not the correct way to handle generated files within a repository if we want > to > maintain the ability to make changes or debug years down the line. Yes these are good points. The rtems-central repo is not a requirement for rtems.git and never will be. The separation was agreed to before any qual work started. The rtems.git repo can exist and operate without rtems-central however the rtems-central repo is meaningless without rtems.git so Amar I agree the dependency is the wrong way around. I have agreed to generated content for headers, some tests, and documentation because the generator input is in rtems-central so the effort to maintain that rtems-central data with any manual changes in rtems.git etc is part of the overhead of maintaining rtems-central. The build spec files are in rtems.git and this relationship is very different. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 2/3] build: Replace variant patterns with a list
On 18/1/2023 6:00 pm, Sebastian Huber wrote: > On 18.01.23 04:59, Chris Johns wrote: >> Hi Sebastian, >> >> I had not got to this part of the patch set because the other was being >> discussed. I thought a patch set was considerd as a whole rather than having >> to >> deal with the extra complexity of possible splits and if they exist? If this >> was >> pull request or merge request in a tool none of this patch set would have >> been >> applied unless split into separate merge reguests. :) > > Sorry, I thought you were already finished with the patch set. Maybe we should > move the patch review to pull requests. I am still buried after being away and no I was not finsihed. I am sorry for the confusion. >> Why has this been done? > > The enabled-by expressions used in patch 3 do not support regular expressions. I did not pick that up. Why was that regx functionality removed? Is it related to scripting and rtems-central? >> Why the noise in the patch of only lines being moved? Where has this come >> from? >> Is there a new requirement spec fields be in some osrt of order? > > I did the change with a script which sorted the lists. In general, the lists > should be sorted. This is a good example of problems a lack of scripting support along side the build spec files creates. It makes manual changes difficult when rules get layered like this plus it means you are the only one who can make generated changes without there being a clash of scripting specifics, ie my script vs your script or something like that. And I have no intention in cloning rtems-central and learning how to use it. There was a primary agreement for the separation of all qual work and the ability for it to be removed from the project without any side effects. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Build error microblaze
Getting the following build error when building microblaze, and wanted to see if anyone else has run into this issue. I think I'm supposed to be using master on lib bsd and not 6-freebsd-12. [1303/1988] Compiling freebsd/sys/netinet/libalias/alias_skinny.c ../../freebsd/sys/netinet/sctp_output.c:61:10: fatal error: machine/in_cksum.h: No such file or directory 61 | #include Lib bsd hash * 7a12651b (HEAD -> master, navigator/master) libbsd: Add TFTP filesystem to test media01 Rtems hash | * 5b124432e2 (HEAD -> master, origin/master, origin/HEAD) build: Fix copyright statement format -- Sincerely, Sam Price ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 2/3] build: Replace variant patterns with a list
On 19.01.23 01:17, Chris Johns wrote: Why has this been done? The enabled-by expressions used in patch 3 do not support regular expressions. I did not pick that up. Why was that regx functionality removed? Is it related to scripting and rtems-central? The enabled-by expressions supported by the wscript don't support regular expressions: https://github.com/RTEMS/rtems/blob/master/wscript#L144 The interesting part of the patch set is patch 3: Merge the "default" and "default-by-variant" attributes. Use an "enabled-by" expression to select the default value based on the enabled set. This makes it possible to select default values depending on other options. For example you could choose memory settings based on whether RTEMS_SMP is enabled or disabled. Why the noise in the patch of only lines being moved? Where has this come from? Is there a new requirement spec fields be in some osrt of order? I did the change with a script which sorted the lists. In general, the lists should be sorted. This is a good example of problems a lack of scripting support along side the build spec files creates. It makes manual changes difficult when rules get layered like this plus it means you are the only one who can make generated changes without there being a clash of scripting specifics, ie my script vs your script or something like that. I don't understand what is the problem with the sorted lists. If you have a list of unordered phrases, it is not unusual to still sort them in lexicographic order. And I have no intention in cloning rtems-central and learning how to use it. There was a primary agreement for the separation of all qual work and the ability for it to be removed from the project without any side effects. You don't have to use the stuff in rtems-central, it could be just more convenient and efficient. It would be possible to write a Github action which checks that the build items match the expected format for pull requests. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 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
Re: [PATCH 1/3] build: Format build items
On 18.01.23 22:58, Amar Takhar wrote: On 2023-01-17 08:39 +0100, Sebastian Huber wrote: The Python modules to work with specification items are in rtems-central.git. This repository contains also a format specification of the build items. We could add an action to a Github work flow to check the build item format for pull requests and commits. I don't chime in here very often but after seeing the recent changes I'm extremely confused. There are now tools that sit outside of the RTEMS repository that now change source files in RTEMS? I have never seen it done this way before. What version of this tool have you used? How can anyone in the future possibly debug this? In rtems-central.git there are Python modules and scripts which generate source, header, and documentation files from specification items. This repository contains the pre-qualification support for RTEMS. By accident, a part of the build system uses also specification items. So, if you want to change the format of the items, you can use the tooling available in rtems-central.git to do this. An example is the recent merge of the "default" and "default-by-variant" attributes. What should happen here is this tools should sit in the main repository. Any required changes made and then a command run to generate new output: ./waf This lets us know that the output in this commit was generated by code existing in the previous commit. There is no need to version anything it's already done. Having it sitting outside of the source repository makes debugging impossible. Case in point is the commit message here. No explanation as to where these changes have come from. No commit version. I spent a very long time figuring out what was going on and I could not figure it out without digging through the lists. The changes were made by a 10 liner throw away script. I could have done the changes also manually it would be just more work. How is anyone in 5, 10, 15 years down the road going to sort through this? What if I want to make a change in 10 years and regenerate. It is impossible as I have no idea what's been done let alone where to look. There is nothing to regenerate. The patch set contains simple format changes and a transformation of attributes. However, your concern is still valid for the generated files, for example https://github.com/RTEMS/rtems/blob/master/cpukit/include/rtems.h which is generated from https://github.com/RTEMS/rtems-central/blob/master/spec/rtems/if/header.yml Most of the Classic API header files are generated from specification items. If nobody takes care that rtems-central.git is used and stays up to date the specification will get out of synchronization with rtems.git. I'm not against the purpose of the tool or the work has been done but this is not the correct way to handle generated files within a repository if we want to maintain the ability to make changes or debug years down the line. I would use a single repository for RTEMS just like the FreeBSD base system, but this is another discussion. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 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
