diff --git a/.ci b/.ci index 0e93b7085..261f218e0 160000 --- a/.ci +++ b/.ci @@ -1 +1 @@ -Subproject commit 0e93b708551cb7bb212fda7029eccdf872dabc81 +Subproject commit 261f218e094e39550e3a7c54b98e34adcf42ad9b diff --git a/.github/workflows/ci-scripts-build.yml b/.github/workflows/ci-scripts-build.yml index 3ac88a6c0..c1e2b90d3 100644 --- a/.github/workflows/ci-scripts-build.yml +++ b/.github/workflows/ci-scripts-build.yml @@ -50,9 +50,9 @@ jobs: matrix: # Job names also name artifacts, character limitations apply include: - - os: ubuntu-24.04 + - name: "Ub-24 gcc c++20 Werror" + os: ubuntu-24.04 cmp: gcc - name: "Ub-24 gcc-13 c++20 Werror" # Turn all warnings into errors, # except for those we could not fix (yet). # Remove respective -Wno-error=... flag once it is fixed. @@ -73,127 +73,141 @@ jobs: -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3' CMD_LDFLAGS=-Wl,-z,relro" - - os: ubuntu-22.04 - cmp: gcc - configuration: default - cross: "windows-x64-mingw" - name: "Ub-22 gcc + MinGW" - - - os: ubuntu-22.04 - cmp: gcc - configuration: static - cross: "windows-x64-mingw" - name: "Ub-22 gcc + MinGW, static" - - - os: ubuntu-22.04 + - name: "Ub-22 gcc C++11, static" + os: ubuntu-22.04 cmp: gcc configuration: static extra: "CMD_CXXFLAGS=-std=c++11" - name: "Ub-22 gcc C++11, static" - - os: ubuntu-22.04 + - name: "Ub-22 gcc u-char" + os: ubuntu-22.04 cmp: gcc configuration: static extra: "CMD_CFLAGS=-funsigned-char CMD_CXXFLAGS=-funsigned-char" - name: "Ub-22 gcc unsigned char" - - os: ubuntu-22.04 + - name: "Ub-22 clang" + os: ubuntu-22.04 cmp: clang configuration: default - name: "Ub-22 clang" - - os: ubuntu-22.04 + - name: "Ub-22 clang C++11" + os: ubuntu-22.04 cmp: clang configuration: default extra: "CMD_CXXFLAGS=-std=c++11" - name: "Ub-22 clang C++11" - - os: ubuntu-22.04 + - name: "MacOS clang" + os: macos-latest + cmp: clang + configuration: default + + # Cross builds + + - name: "Ub gcc + linux-aarch64" + os: ubuntu-latest + cmp: gcc + configuration: default + cross: "linux-aarch64" + + - name: "Ub gcc + linux-arm gnueabi" + os: ubuntu-latest + cmp: gcc + configuration: default + cross: "linux-arm@arm-linux-gnueabi" + + - name: "Ub gcc + linux-arm gnueabihf" + os: ubuntu-latest + cmp: gcc + configuration: default + cross: "linux-arm@arm-linux-gnueabihf" + + - name: "Ub-22 gcc + MinGW" + os: ubuntu-22.04 + cmp: gcc + configuration: default + cross: "windows-x64-mingw" + + - name: "Ub-22 gcc + MinGW, static" + os: ubuntu-22.04 + cmp: gcc + configuration: static + cross: "windows-x64-mingw" + + - name: "Ub-22 gcc + RT-4.9 pc386" + os: ubuntu-22.04 + cmp: gcc + configuration: default + cross: "RTEMS-pc386-qemu@4.9" + + - name: "Ub-22 gcc + RT-4.10 pc386" + os: ubuntu-22.04 + cmp: gcc + configuration: default + cross: "RTEMS-pc386-qemu@4.10" + test: NO + + - name: "Ub-22 gcc + RT-5.1 pc686" + os: ubuntu-22.04 cmp: gcc configuration: default cross: "RTEMS-pc686-qemu@5" - name: "Ub-22 gcc + RT-5.1 pc686" - - os: ubuntu-22.04 + - name: "Ub-22 gcc + RT-5.1 beatnik" + os: ubuntu-22.04 cmp: gcc configuration: default cross: "RTEMS-beatnik@5" test: NO - name: "Ub-22 gcc + RT-5.1 beatnik" - - os: ubuntu-22.04 + - name: "Ub-22 gcc + RT-5.1 xilinx_zynq_a9_qemu" + os: ubuntu-22.04 cmp: gcc configuration: default cross: "RTEMS-xilinx_zynq_a9_qemu@5" test: NO - name: "Ub-22 gcc + RT-5.1 xilinx_zynq_a9_qemu" - - os: ubuntu-22.04 + - name: "Ub-22 gcc + RT-5.1 uC5282" + os: ubuntu-22.04 cmp: gcc configuration: default cross: "RTEMS-uC5282@5" test: NO - name: "Ub-22 gcc + RT-5.1 uC5282" - - os: ubuntu-22.04 - cmp: gcc - configuration: default - name: "Ub-22 gcc + RT-4.10" - cross: "RTEMS-pc386-qemu@4.10" - test: NO + # Windows builds - - os: ubuntu-22.04 - cmp: gcc - configuration: default - name: "Ub-22 gcc + RT-4.9" - cross: "RTEMS-pc386-qemu@4.9" - - - os: macos-latest - cmp: clang - configuration: default - name: "MacOS clang" - - - os: windows-2022 + - name: "Win-22 MSC-22" + os: windows-2022 cmp: vs2022 configuration: debug - name: "Win-22 MSC-22" - extra: "CMD_CXXFLAGS=-analysis" + extra: "CMD_CXXFLAGS=-analyze" - - os: windows-2022 + - name: "Win-22 MSC-22, static" + os: windows-2022 cmp: vs2022 configuration: static-debug - name: "Win-22 MSC-22, static" - extra: "CMD_CXXFLAGS=-analysis" + extra: "CMD_CXXFLAGS=-analyze" - - os: windows-2022 + - name: "Win-22 MSC-22, debug" + os: windows-2022 cmp: vs2022 configuration: debug - name: "Win-22 MSC-22, debug" - - os: windows-2022 + - name: "Win-22 MSC-22 c++14, debug" + os: windows-2022 + cmp: vs2022 + configuration: debug + extra: "CMD_CXXFLAGS='-analyze -Zc:__cplusplus -std:c++14'" + + - name: "Win-22 MSC-22 c++17, debug" + os: windows-2022 + cmp: vs2022 + configuration: debug + extra: "CMD_CXXFLAGS='-analyze -Zc:__cplusplus -std:c++17'" + + - name: "Win-22 mingw" + os: windows-2022 cmp: gcc configuration: default - name: "Win-22 mingw" - - # Cross builds - - - os: ubuntu-latest - cmp: gcc - configuration: default - name: "Cross linux-aarch64" - cross: linux-aarch64 - - - os: ubuntu-latest - cmp: gcc - configuration: default - name: "Cross linux-arm gnueabi" - cross: linux-arm@arm-linux-gnueabi - - - os: ubuntu-latest - cmp: gcc - configuration: default - name: "Cross linux-arm gnueabihf" - cross: linux-arm@arm-linux-gnueabihf steps: - uses: actions/checkout@v4 diff --git a/.gitignore b/.gitignore index 412314940..529025933 100644 --- a/.gitignore +++ b/.gitignore @@ -1,3 +1,5 @@ +# Before adding patterns here, please read the gitignore +# documentation at https://git-scm.com/docs/gitignore /cfg/ /bin/ /lib/ @@ -11,14 +13,13 @@ /modules/RELEASE.*.local /modules/Makefile.local O.*/ -/QtC-* -/.qtc_* -/.vscode/ -*.orig *.log -.*.swp -.DS_Store .iocsh_history + +# Common files generated by other tools +.DS_Store + +# Files created by rpmbuild RPMS SRPMS BUILDROOT diff --git a/README b/README index 942d00cb3..da2492989 100644 --- a/README +++ b/README @@ -13,15 +13,7 @@ this distribution. --------------------------------------------------------- -Installation and release information can be found in the -various files in the documentation subdirectory. - -Additional information about EPICS including mailing list -archives and subscription instructions, documentation and -training materials, additional components, links to other -websites etc. is available on the EPICS home page at - https://epics.anl.gov/ +For more information, see the README.md file. $Format:%cD$ $Format:%H$ -https://code.launchpad.net/epics-base diff --git a/README.md b/README.md new file mode 100644 index 000000000..66c719c93 --- /dev/null +++ b/README.md @@ -0,0 +1,64 @@ + +# EPICS Base + +EPICS (Experimental Physics and Industrial Control System) is a set of software +tools and applications which provide a software infrastructure for use in +building distributed control systems to operate devices such as Particle +Accelerators, Large Experiments and major Telescopes. EPICS Base is the central +core of the control system toolkit. More details can be found at the +[About page of the official website](https://epics-controls.org/about-epics/) + +## Links + +- [Official Website](https://epics-controls.org/) +- [Original Website](https://epics.anl.gov/) +- [Repository](https://github.com/epics-base/epics-base) + +### Documentation + +- [Documentation](https://docs.epics-controls.org/en/latest/) +- [Documentation Repository](https://github.com/epics-docs/epics-docs) + +### Community Communication + +- [Tech-Talk Mailing List](https://epics.anl.gov/tech-talk/) +- [Matrix Rooms](https://matrix.to/#/#epics:epics-controls.org) +- [News](https://epics-controls.org/news-and-events/) + +## Quick Install + +Download a release from the +[Downloads page](https://epics-controls.org/resources-and-support/base/downloads) +and unpack it. Inside the unpacked folder run: + +```bash +make +``` + +For more information on how to install on your system see the +[Installation page](https://docs.epics-controls.org/en/latest/getting-started/installation.html) +of the documentation. + +### Quick run a softIOC + +After building, you can run an example soft-IOC (Input/Output Controller) +which runs a Channel Access server. + +```bash +./bin/*/softIoc -x first +``` + +Run the `dbl` command to list the records it provides: + +```bash +epics> dbl +first:BaseVersion +first:exit +epics> +``` + +## License + +EPICS Base is distributed subject to a Software License +Agreement found in the file [LICENSE](./LICENSE) that is included with +this distribution. diff --git a/configure/CONFIG.gnuCommon b/configure/CONFIG.gnuCommon index a6305990b..63a32eca1 100644 --- a/configure/CONFIG.gnuCommon +++ b/configure/CONFIG.gnuCommon @@ -65,7 +65,7 @@ LOADABLE_SHRLIB_LDFLAGS = -shared -fPIC -Wl,-h$@ GNU_LDLIBS_YES = -lgcc -# Use compiler flags to generate header dependancies files +# Use compiler flags to generate header dependencies files HDEPENDS_METHOD = COMP HDEPENDS_COMPFLAGS = -MM -MF $@ diff --git a/configure/CONFIG_ADDONS b/configure/CONFIG_ADDONS index d32d91165..5b581f48c 100644 --- a/configure/CONFIG_ADDONS +++ b/configure/CONFIG_ADDONS @@ -24,7 +24,7 @@ # These rules apply to these Makefile-variables: # USR_CFLAGS C flags # USR_CXXFLAGS C++ flags -# USR_CPPFLAGS c preprocesser flags +# USR_CPPFLAGS c preprocessor flags # SRCS source files for building libraries and prods # USR_SRCS source files for building libraries and prods # PROD_SRCS source files for building prods diff --git a/configure/CONFIG_BASE_VERSION b/configure/CONFIG_BASE_VERSION index eeb577824..a05861956 100644 --- a/configure/CONFIG_BASE_VERSION +++ b/configure/CONFIG_BASE_VERSION @@ -48,7 +48,7 @@ EPICS_VERSION = 7 EPICS_REVISION = 0 # EPICS_MODIFICATION must be a number >=0 and <256 -EPICS_MODIFICATION = 9 +EPICS_MODIFICATION = 10 # EPICS_PATCH_LEVEL must be a number (win32 resource file requirement) # Not included in the official EPICS version number if zero diff --git a/configure/CONFIG_CA_VERSION b/configure/CONFIG_CA_VERSION index 770e1965f..de8fd6ba1 100644 --- a/configure/CONFIG_CA_VERSION +++ b/configure/CONFIG_CA_VERSION @@ -1,8 +1,8 @@ # Version number for the Channel Access API and shared library EPICS_CA_MAJOR_VERSION = 4 -EPICS_CA_MINOR_VERSION = 14 -EPICS_CA_MAINTENANCE_VERSION = 6 +EPICS_CA_MINOR_VERSION = 15 +EPICS_CA_MAINTENANCE_VERSION = 1 # Development flag, set to zero for release versions diff --git a/configure/CONFIG_COMMON b/configure/CONFIG_COMMON index 9165ae294..c37b47238 100644 --- a/configure/CONFIG_COMMON +++ b/configure/CONFIG_COMMON @@ -147,7 +147,7 @@ CMPLR_SRC_DIRS += . $(foreach dir, .. $(SRC_DIRS), \ ALL_SRC_DIRS = $(CMPLR_SRC_DIRS) $(OS_SRC_DIRS) $(GENERIC_SRC_DIRS) #-------------------------------------------------- -# Directory for OS independant build created files +# Directory for OS independent build created files COMMON_DIR = ../O.Common # compile line include directories diff --git a/configure/CONFIG_DATABASE_VERSION b/configure/CONFIG_DATABASE_VERSION index 5c5eae1ee..94f4872e7 100644 --- a/configure/CONFIG_DATABASE_VERSION +++ b/configure/CONFIG_DATABASE_VERSION @@ -1,7 +1,7 @@ # Version number for the database APIs and shared library EPICS_DATABASE_MAJOR_VERSION = 3 -EPICS_DATABASE_MINOR_VERSION = 24 +EPICS_DATABASE_MINOR_VERSION = 25 EPICS_DATABASE_MAINTENANCE_VERSION = 1 # Development flag, set to zero for release versions diff --git a/configure/CONFIG_ENV b/configure/CONFIG_ENV index 6d0d52a79..3ec50c020 100644 --- a/configure/CONFIG_ENV +++ b/configure/CONFIG_ENV @@ -53,3 +53,5 @@ EPICS_IOC_IGNORE_SERVERS="" # EPICS_IOC_LOG_PORT Log server port number etc. EPICS_IOC_LOG_PORT=7004 +# Posix priority scheduling +EPICS_ALLOW_POSIX_THREAD_PRIORITY_SCHEDULING=YES diff --git a/configure/CONFIG_LIBCOM_VERSION b/configure/CONFIG_LIBCOM_VERSION index 7f1487489..405906813 100644 --- a/configure/CONFIG_LIBCOM_VERSION +++ b/configure/CONFIG_LIBCOM_VERSION @@ -1,7 +1,7 @@ # Version number for the libcom APIs and shared library EPICS_LIBCOM_MAJOR_VERSION = 3 -EPICS_LIBCOM_MINOR_VERSION = 24 +EPICS_LIBCOM_MINOR_VERSION = 25 EPICS_LIBCOM_MAINTENANCE_VERSION = 1 # Development flag, set to zero for release versions diff --git a/configure/RULES.Db b/configure/RULES.Db index 4a984f8c3..ae023cee1 100644 --- a/configure/RULES.Db +++ b/configure/RULES.Db @@ -55,7 +55,7 @@ DBD += $(foreach type, $(CROSS_TARGET_OS_TYPES), $(DBD_$(type))) # DBD_solaris += abcSolaris.dbd # # --------------------------------------------------- -# DBD concatination files +# DBD concatenation files COMMON_DBDCATS += $(addprefix $(COMMON_DIR)/,$(DBDCAT)) DBDCAT_SOURCES += $(foreach file, $($*_DBD), $(DBDCAT_SOURCE) ) @@ -194,7 +194,7 @@ ifneq (,$(strip $(DBDDEPENDS_FILES))) endif #--------------------------------------------------------------- -# build dependancies, clean rule +# build dependencies, clean rule inc: $(COMMON_INC) $(INSTALL_INC) $(COMMON_DBDS) $(COMMON_DBDCATS) \ $(INSTALL_DBDS) $(INSTALL_DBD_INSTALLS) $(COMMON_DOCS) diff --git a/configure/RULES_ARCHS b/configure/RULES_ARCHS index 4aaa75870..0d4d944d4 100644 --- a/configure/RULES_ARCHS +++ b/configure/RULES_ARCHS @@ -32,7 +32,7 @@ ifneq ($(RELEASE_CFG_DIR_RULES),) include $(RELEASE_CFG_DIR_RULES) endif -# Create EPICS_HOST_ARCH dependancies for GNU make -j option. +# Create EPICS_HOST_ARCH dependencies for GNU make -j option. # Needed in dirs where EPICS_HOST_ARCH build creates a tool used in # cross arch builds diff --git a/configure/RULES_DIRS b/configure/RULES_DIRS index f47df4a53..6314c530f 100644 --- a/configure/RULES_DIRS +++ b/configure/RULES_DIRS @@ -44,7 +44,7 @@ $(foreach dir, $(DIRS), $(dir)$(DIVIDER)install): \ rebuild: $(foreach dir, $(DIRS), $(dir)$(DIVIDER)install) endif -# Create directory dependancies lines for GNU make -j option +# Create directory dependencies lines for GNU make -j option # Only works with GNU make 3.81 or later (uses eval function) define DEP_template1 $(1): $$($(1)_DEPEND_DIRS) diff --git a/configure/Sample.Makefile b/configure/Sample.Makefile index e0e9675bf..0c0b313e2 100644 --- a/configure/Sample.Makefile +++ b/configure/Sample.Makefile @@ -82,7 +82,7 @@ INC = file.h # Platform specific files can also be put in # separate os/OS_CLASS directories! # -# For almost every file the seach order is: +# For almost every file the search order is: # ./os/OS_CLASS # ./os/generic # . @@ -136,11 +136,11 @@ PROD_SRCS = ppp.c qqq.c a_file_SRCS = aa.c bb.c # -# EPICS libs needed to link PROD, TESTPROD and sharable library +# EPICS libs needed to link PROD, TESTPROD and shareable library # # note that DLL_LIBS (the libraries needed to link a shareable # library) is created by default from the PROD/SYS libraries specified -# below minus the name of the sharable library (LIBRARY) +# below minus the name of the shareable library (LIBRARY) # # # ---------- libraries for a specific product pppp @@ -169,7 +169,7 @@ USR_LIBS_DEFAULT = foolib USR_LIBS_WIN32 = -nil- foolib_DIR = $(FOO_LIB) -# system libs needed to link PROD, TESTPROD and sharable library +# system libs needed to link PROD, TESTPROD and shareable library # # ---------- system libraries for all products # for all systems: diff --git a/configure/os/CONFIG.Common.RTEMS-beagleboneblack b/configure/os/CONFIG.Common.RTEMS-beagleboneblack index 4b6107b05..edda91b9d 100644 --- a/configure/os/CONFIG.Common.RTEMS-beagleboneblack +++ b/configure/os/CONFIG.Common.RTEMS-beagleboneblack @@ -9,7 +9,7 @@ RTEMS_BSP = beagleboneblack RTEMS_TARGET_CPU = arm GNU_TARGET = arm-rtems -OP_SYS_LDLIBS += -Wl,--gc-sections +OP_SYS_LDFLAGS += -Wl,--gc-sections ARCH_DEP_LDFLAGS = -L$(RTEMS_BASE)/$(GNU_TARGET)$(RTEMS_VERSION)/beagleboneblack/lib/ include $(CONFIG)/os/CONFIG.Common.RTEMS diff --git a/configure/os/CONFIG.Common.RTEMS-pc686 b/configure/os/CONFIG.Common.RTEMS-pc686 index bfe4c26e4..5d30b17d8 100644 --- a/configure/os/CONFIG.Common.RTEMS-pc686 +++ b/configure/os/CONFIG.Common.RTEMS-pc686 @@ -20,7 +20,6 @@ define MUNCH_CMD $(RTEMS_TOOLS)/bin/$(OBJCOPY_FOR_TARGET) -O binary -R .comment -S $< $@ endef -OP_SYS_LDLIBS += -Wl,--gc-sections ARCH_DEP_LDFLAGS = -L$(RTEMS_BASE)/$(GNU_TARGET)$(RTEMS_VERSION)/pc686/lib/ include $(CONFIG)/os/CONFIG.Common.RTEMS @@ -28,7 +27,7 @@ include $(CONFIG)/os/CONFIG.Common.RTEMS # # Put text segment where it will work with etherboot # -OP_SYS_LDFLAGS += -Wl,-Ttext,0x100000 +OP_SYS_LDFLAGS += -Wl,-Ttext,0x100000 -Wl,--gc-sections # This check must appear after the above include diff --git a/configure/os/CONFIG.Common.RTEMS-qoriq_e500 b/configure/os/CONFIG.Common.RTEMS-qoriq_e500 index 94c7e825e..234c2e4f4 100644 --- a/configure/os/CONFIG.Common.RTEMS-qoriq_e500 +++ b/configure/os/CONFIG.Common.RTEMS-qoriq_e500 @@ -20,7 +20,7 @@ ARCH_DEP_CFLAGS += -DRTEMS_HAS_ALTIVEC #ARCH_DEP_CFLAGS += -I$(RTEMS_BASE)/powerpc-rtems5/qoriq_e500/lib/include #OP_SYS_LDLIBS += -lbspExt #does not use posix stuff ... want to ignore -OP_SYS_LDLIBS += -Wl,--gc-sections +OP_SYS_LDFLAGS += -Wl,--gc-sections #ARCH_DEP_LDFLAGS = -mcpu=8540 -meabi -msdata=sysv -mstrict-align -mspe -mabi=spe -mfloat-gprs=double ARCH_DEP_LDFLAGS = -L$(RTEMS_BASE)/$(GNU_TARGET)$(RTEMS_VERSION)/$(RTEMS_BSP)/lib diff --git a/configure/os/CONFIG.Common.RTEMS-xilinx_zynq_a9_qemu b/configure/os/CONFIG.Common.RTEMS-xilinx_zynq_a9_qemu index 83b518b69..51cd286ae 100644 --- a/configure/os/CONFIG.Common.RTEMS-xilinx_zynq_a9_qemu +++ b/configure/os/CONFIG.Common.RTEMS-xilinx_zynq_a9_qemu @@ -12,7 +12,7 @@ GNU_TARGET = arm-rtems #use dhcp/bootp ARCH_DEP_CFLAGS += -DMY_DO_BOOTP=NULL -OP_SYS_LDLIBS += -Wl,--gc-sections +OP_SYS_LDFLAGS += -Wl,--gc-sections ARCH_DEP_LDFLAGS = -L$(RTEMS_BASE)/$(GNU_TARGET)$(RTEMS_VERSION)/xilinx_zynq_a9_qemu/lib/ diff --git a/configure/os/CONFIG.Common.RTEMS-xilinx_zynq_microzed b/configure/os/CONFIG.Common.RTEMS-xilinx_zynq_microzed new file mode 100644 index 000000000..212b1b16f --- /dev/null +++ b/configure/os/CONFIG.Common.RTEMS-xilinx_zynq_microzed @@ -0,0 +1,16 @@ +# +# CONFIG.Common.RTEMS-xilinx_zynq_microzed +# Author: Chris Johns +# +# All RTEMS targets use the same Makefile fragment +# +#EXE = .elf +RTEMS_BSP = xilinx_zynq_microzed +RTEMS_TARGET_CPU = arm +GNU_TARGET = arm-rtems + +OP_SYS_LDLIBS += -Wl,--gc-sections +ARCH_DEP_LDFLAGS = -L$(RTEMS_BASE)/$(GNU_TARGET)$(RTEMS_VERSION)/xilinx_zynq_microzed/lib/ + + +include $(CONFIG)/os/CONFIG.Common.RTEMS diff --git a/configure/os/CONFIG.Common.RTEMS-xilinx_zynq_zedboard b/configure/os/CONFIG.Common.RTEMS-xilinx_zynq_zedboard index bac33eb91..f745b15d6 100644 --- a/configure/os/CONFIG.Common.RTEMS-xilinx_zynq_zedboard +++ b/configure/os/CONFIG.Common.RTEMS-xilinx_zynq_zedboard @@ -9,7 +9,7 @@ RTEMS_BSP = xilinx_zynq_zedboard RTEMS_TARGET_CPU = arm GNU_TARGET = arm-rtems -OP_SYS_LDLIBS += -Wl,--gc-sections +OP_SYS_LDFLAGS += -Wl,--gc-sections ARCH_DEP_LDFLAGS = -L$(RTEMS_BASE)/$(GNU_TARGET)$(RTEMS_VERSION)/xilinx_zynq_zedboard/lib/ diff --git a/configure/os/CONFIG_SITE.linux-x86.linux-x86 b/configure/os/CONFIG_SITE.linux-x86.linux-x86 index 64810a835..ee7484e04 100644 --- a/configure/os/CONFIG_SITE.linux-x86.linux-x86 +++ b/configure/os/CONFIG_SITE.linux-x86.linux-x86 @@ -3,7 +3,7 @@ # Site specific definitions for linux-x86 host - linux-x86 target builds #------------------------------------------------------- -# Uncomment the followings lines to build with CLANG instead of GCC. +# Uncomment the following lines to build with CLANG instead of GCC. # #GNU = NO #CMPLR_CLASS = clang diff --git a/configure/os/CONFIG_SITE.linux-x86_64.linux-x86_64 b/configure/os/CONFIG_SITE.linux-x86_64.linux-x86_64 index 2f538151a..bdedf4f2c 100644 --- a/configure/os/CONFIG_SITE.linux-x86_64.linux-x86_64 +++ b/configure/os/CONFIG_SITE.linux-x86_64.linux-x86_64 @@ -3,7 +3,7 @@ # Site specific definitions for linux-x86_64 host - linux-x86_64 target builds #------------------------------------------------------- -# Uncomment the followings lines to build with CLANG instead of GCC. +# Uncomment the following lines to build with CLANG instead of GCC. # #GNU = NO #CMPLR_CLASS = clang diff --git a/documentation/Doxyfile@ b/documentation/Doxyfile@ index 2c0289602..ef2377119 100644 --- a/documentation/Doxyfile@ +++ b/documentation/Doxyfile@ @@ -1105,7 +1105,7 @@ HTML_STYLESHEET = # cascading style sheets that are included after the standard style sheets # created by doxygen. Using this option one can overrule certain style aspects. # This is preferred over using HTML_STYLESHEET since it does not replace the -# standard style sheet and is therefor more robust against future updates. +# standard style sheet and is therefore more robust against future updates. # Doxygen will copy the style sheet files to the output directory. # Note: The order of the extra stylesheet files is of importance (e.g. the last # stylesheet in the list overrules the setting of the previous ones in the @@ -1648,8 +1648,8 @@ EXTRA_PACKAGES = # Note: Only use a user-defined header if you know what you are doing! The # following commands have a special meaning inside the header: $title, # $datetime, $date, $doxygenversion, $projectname, $projectnumber, -# $projectbrief, $projectlogo. Doxygen will replace $title with the empy string, -# for the replacement values of the other commands the user is refered to +# $projectbrief, $projectlogo. Doxygen will replace $title with the empty string, +# for the replacement values of the other commands the user is referred to # HTML_HEADER. # This tag requires that the tag GENERATE_LATEX is set to YES. diff --git a/documentation/Makefile b/documentation/Makefile index d0ea3a273..059474016 100644 --- a/documentation/Makefile +++ b/documentation/Makefile @@ -21,6 +21,7 @@ RTD_SRC = $(COMMON_DIR)/rtd-src DOCS += README.md DOCS += ca-cli.md +DOCS += ReleaseChecklist.md OLD_NOTES = $(wildcard ../RELEASE-*.md) DOCS += $(OLD_NOTES:../%=%) diff --git a/documentation/Makefile.headers b/documentation/Makefile.headers index 802755c00..016af88ca 100644 --- a/documentation/Makefile.headers +++ b/documentation/Makefile.headers @@ -64,6 +64,7 @@ ca_HEADERS += caerr ca_HEADERS += caeventmask ca_HEADERS += db_access +database_HEADERS += callback database_HEADERS += chfPlugin database_HEADERS += dbChannel database_HEADERS += dbCommon diff --git a/documentation/RELEASE-3.15.md b/documentation/RELEASE-3.15.md index c304a461b..aa31805ee 100644 --- a/documentation/RELEASE-3.15.md +++ b/documentation/RELEASE-3.15.md @@ -191,7 +191,7 @@ parameter with one called `EPICS_TZ` and a routine for VxWorks that calculates the `TIMEZONE` environment variable from the current `TZ` value. This routine will be run once at start-up, when the EPICS clock has synchronized to its NTP server. The calculations it contains were worked out and donated to EPICS by -Larry Hoff in 2009; it is unforunate that it has taken 10 years for them to be +Larry Hoff in 2009; it is unfortunate that it has taken 10 years for them to be integrated into Base. The default value for the `EPICS_TZ` environment parameter is set in the Base @@ -521,7 +521,7 @@ a Windows system and an IOC or PCAS server is started, the IOC's attempt to bind a TCP socket to the CA server port number fails, but Windows returns a different error status value than the IOC is expecting in that circumstance (because the National Instruments code requests exclusive use of that port, -unlike the EPICS code) so the IOC fails to start properly. The relevent EPICS +unlike the EPICS code) so the IOC fails to start properly. The relevant EPICS bind() checks have now been updated so the IOC will request that a dynamic port number be allocated for this TCP socket instead when this happens. @@ -619,7 +619,7 @@ static versions of the compiler support libraries have now been moved into the The `iocInit` code now performs a sanity check of the current time returned by the generalTime subsystem and will print a warning if the wall-clock time returned has not been initialized yet. This is just a warning message; when -a time provider does synchonize the IOC will subsequently pick up and use the +a time provider does synchronize the IOC will subsequently pick up and use the correct time. This check code also primes the registered event system provider if there is one so the `epicsTimeGetEventInt()` routine will work on IOCs that ask for event time within an interrupt service routine. @@ -642,7 +642,7 @@ change will not cause the IOC to see time going backwards. ### Microsoft Visual Studio builds The build configuration files for builds using the Microsoft compilers have been -updated, although there should be no noticable difference at most sites. One +updated, although there should be no noticeable difference at most sites. One extra compiler warning is now being suppressed for C++ code, `C4344: behavior change: use of explicit template arguments results in ...` which is gratuitous and was appearing frequently in builds of the EPICS V4 modules. diff --git a/documentation/RELEASE-3.16.md b/documentation/RELEASE-3.16.md index 32656ba5d..5f9602ca3 100644 --- a/documentation/RELEASE-3.16.md +++ b/documentation/RELEASE-3.16.md @@ -661,7 +661,7 @@ the `DB_OPT` build configuration variable. The compressRecord has a new field `BALG` which can select between FIFO (append) and LIFO (prepend) ordering for insertion of new elements. FIFO -ordering is the default, matching the behviour of previous versions. +ordering is the default, matching the behaviour of previous versions. ### Valgrind Instrumentation diff --git a/documentation/RELEASE-7.0.1.1.md b/documentation/RELEASE-7.0.1.1.md index ee61fdcf9..3e0bbd467 100644 --- a/documentation/RELEASE-7.0.1.1.md +++ b/documentation/RELEASE-7.0.1.1.md @@ -59,7 +59,7 @@ been split into 4 separate Git repositories. External modules should build against this new structure with little or no changes needed, except that some allowance may be needed for the merging of the V4 modules. -There should be rather more description and documantation of these changes +There should be rather more description and documentation of these changes than is currently available, but as developers we generally much prefer to write code than documentation. Send questions to the tech-talk mailing list and we'll be happy to try and answer them! diff --git a/documentation/RELEASE-7.0.10.md b/documentation/RELEASE-7.0.10.md new file mode 100644 index 000000000..e626bc0da --- /dev/null +++ b/documentation/RELEASE-7.0.10.md @@ -0,0 +1,431 @@ +# Release Notes + +This document describes the changes that were included in the release of EPICS +noted below. Release entries are now provided in a separate document for each +version in the EPICS 7 series, but all are combined into a single page for +publishing on the EPICS website. Separate release documents are also included +from the older Base 3.15 and 3.16 series. + +The external PVA submodules continue to maintain their own release notes files +as before, but the entries describing changes in those submodules since version +7.0.5 have been copied into the associated EPICS Release Notes files; they will +also be manually added to new EPICS Release Notes published in the future. + + +## EPICS Release 7.0.10 + +### Reduce symbol and macro pollution from epicsAtomic.h on WIN32 + +`epicsAtomic.h` no longer pulls in as many unneeded declarations and macros from +`windows.h`. Prior to this change, including `epicsAtomic.h` at the wrong time +could result in unexpected compiler errors. Due to the nature of `windows.h`, +some unneeded declarations are still pulled in, however the number is greatly reduced. +Code that needs these declarations should explicitly include `windows.h` before `epicsAtomic.h`. + +### New `afterIocRunning` IOC Shell Command Added + +This release incorporates [PR #558](https://github.com/epics-base/epics-base/pull/558) which added a new IOC shell command `afterIocRunning`. This command allows startup scripts to schedule arbitrary commands to be executed automatically after the IOC initialization phase (`iocInit`). + +`afterIocRunning` allows you to write better-structured IOC shell files to include in your startup scripts without tracking where `iocInit` is located (and how IOC is deployed) e.g.: +- to achieve the best maintainability (e.g. encapsulation of the context into one file), +- to improve writing boot sequences, +- to improve IOC startup flexibility and scripting capabilities, +- it replaces the community [`afterInit`](https://github.com/paulscherrerinstitute/iocsh_utilities/blob/master/afterInit.c) and [`doAfterIocInit`](https://github.com/epics-modules/std/blob/master/stdApp/src/delayCmd.cpp) IOC shell commands, +- community usage examples: + - [`pf4filters.iocsh`](https://github.com/epics-modules/optics/blob/master/opticsApp/iocsh/pf4filters.iocsh) - enable/disable with a single comment ([full description](https://github.com/epics-base/epics-base/pull/558#issuecomment-2430057167)) + - [ALS-U autosave management](https://github.com/epics-base/epics-base/pull/558#issuecomment-2430447220) + +#### Features + +- Define commands that run after IOC initialization completes. +- Executes following `iocInit` and `autosave` initialization (important for proper PV configuration). +- Supports any valid IOC shell command as an argument. +- Example usages: + - `afterIocRunning "dbpf "` + - `afterIocRunning "date"` + - `afterIocRunning "dbpf $(P)EvtClkSource-Sel 'Upstream (fanout)'"` + - `afterIocRunning "dbpf $(P)Enable-Sel Enabled"` + +### fdManager file descriptor limit removed + +In order to support file descriptors above 1023, fdManager now uses +`poll()` instead of `select()` on all architectures that support it +(Linux, MacOS, Windows, newer RTEMS). + +### New `dbServerStats()` API for iocStats + +A new routine provides the ability to request channel and client counts from +named server layers that implement the `stats()` method, or to get a summary +of the counts from all registered server layers. A preprocessor macro +`HAS_DBSERVER_STATS` macro is defined in the `dbServer.h` header file to +simplify code that needs to support older versions of Base as well. + +### epicsExport simplifications + +`epicsExportAddress()`, `epicsExportRegistrar()` and `epicsRegisterFunction()` +no longer require to be wrapped in `extern "C" { }` in C++ code. + +### Support for multiline strings in iocsh files + +GitHub [PR #603](https://github.com/epics-base/epics-base/pull/603) + +This update introduces support for multiline strings in IOC shell (iocsh) files. +Previously, string values in iocsh files were limited to a single line, making +it difficult to include longer or formatted text. With this change, users can +now define strings that span multiple lines, improving readability and +flexibility when configuring IOC shell scripts. + +To create a multiline string, end a line with a backslash (`\`). The following +line, including any leading whitespace, will be joined to the previous line. +If the backslash is immediately followed by any character other than a newline, +it will not be treated as a multiline continuation. + +### Enhancement to IOC `dbgrep` command + +`dbgrep` now takes an optional second string argument consisting of a list of field names +separated by spaces, e.g. `dbgrep "*PRESSURE*", "VAL DESC"` + +### ACF Syntax Forward Compatibility + +This release modifies the Access Security Configuration File (ACF) parser to +**standardize the ACF grammar for forward compatibility**. +It does not change the syntax that was accepted by earlier versions of the parser, +so **existing access security configuration files will not need to be modified.** +All ACF definitions will adhere to a consistent syntax format, +which will allow future additions to the access security language +without breaking existing configurations. +In practice, this means the structure of ACF files is now formally defined +and will remain stable going forward, +so any new grammar features will fit into the same pattern. +(Existing ACF files continue to work as-is under the new parser, +so no changes are required for legacy configurations or tools.). + +**Generic ACF Syntax:** +The ACF file consists of definitions for User Access Groups (UAG), +Host Access Groups (HAG), +and Access Security Groups (ASG), +using the following general format +(angle brackets below denote placeholders): + +```text + +UAG() [{ [, ...] }] +... + +HAG() [{ [, ...] }] +... + +ASG() [{ + [INP() + ...] + + RULE(, NONE | READ | WRITE [, NOTRAPWRITE | TRAPWRITE]) { + [UAG( [, ...])] + [HAG( [, ...])] + [CALC()] + } + ... +}] +... + +``` + +Under this schema each definition comprises a keyword, +a name in parentheses, +and (optionally) a braced block of contents. +This uniform structure ensures that +**future keywords or sections** +can be introduced in the same form, +maintaining compatibility with the parser. +For example, if a new type of condition or group is added in a later release, +it would follow the `KEYWORD(name) { ... }` pattern, +so 7.0.10-era parsers can handle or ignore it gracefully +instead of failing on unknown syntax. + +**Supported Syntax in EPICS 7.0.10:** +The current release defines the following specific elements +within the above generic format: + +- **UAG** -- *User Access Group*. +Defines a group of user names. +- **HAG** -- *Host Access Group*. +Defines a group of host names +(or IP addresses) that clients can connect from. +- **ASG** -- *Access Security Group*. +Defines a security group which records can be assigned to. +An ASG entry may contain a block with input definitions and access rules. +For example: + +```text +ASG(MyGroup) { + INPA(myPV1) + INPB(myPV2) + RULE(1, WRITE) { ... } + RULE(1, READ) { ... } +} +``` + +If no rules are defined for an ASG, +the access permissions default to always allowed. + +- **INP()** -- *Input link*. +Declares an input process variable whose value can be used in a CALC condition. +- **RULE(, [, ]) { ... }** -- +Defines an access rule for the ASG. + +Inside the curly braces of a RULE, +**optional conditions** can restrict when that rule applies. +All conditions that are present must be satisfied +(they function as a logical AND): + +- **UAG(, ...)** -- User-group condition. +The rule only applies if the Channel Access client's user +is a member of one of the listed UAGs. +- **HAG(, ...)** -- Host-group condition. +The rule only applies if the client's host +(as determined by its IP or hostname) is in one of the listed HAGs +- **CALC("")** -- Calculation condition. +The rule only applies if the given expression evaluates to true (non-zero). + +**Special Semantics for RULEs:** +Rules will continue to allow the prescribed access if and only if +all the predicates the rule contains are satisfied. +- If the rule contains predicates that are unknown to the parser +(indicating future functionality), +then the rule will NOT not match, +but no syntax error will be reported as long as the syntax is correct. +- If the rule contains predicates that the parser does not recognise +which are malformed (e.g. missing parentheses), +then the rule will not match and the parser will report a syntax error. +- In this way rules can be extended with new predicates +without breaking older clients or giving those older clients elevated privileges. + +**Special Semantics for unrecognised ACF file elements:** +Any elements that are included in an ACF file will be ignored silently +by a parser that does not understand them. +- If an element is seen in an ACF file that is not understood by the parser, +the parser will simply ignore it silently, +without reporting an error, +as long as its syntax is correct. +- If elements are added to the ACF file that are malformed +(e.g. missing parentheses), +the parser will report a syntax error. +- Thus new elements can be added to ACF files in new EPICS releases +without breaking older clients that loads those files. + +In summary, **ACF forward compatibility** +means that from EPICS 7.0.10 onward, +any new access security features will use this established syntax. +The parser will recognize new group types or rule options using the same +`(...) { ... }` convention, +ensuring they can be used in files loaded by IOCs running EPICS 7.0.10 or later +without breaking those IOCs or requiring their parser to be modified. +This change **does not require any modifications to existing ACF files +or downstream tools** -- all legacy syntax remains valid, +and the new standardized grammar provides a robust foundation for future extensions. + +A full EBNF grammar for the new syntax can be found in the +[IOC Access Security](ACF-Language.md) document added to this release. + +### Add `dbglob` to replace `dbgrep` + +A new IOC shell command, `dbglob` has been added, with `dbgrep` becoming +an alias of this new function, with the intent of deprecating it in a +future release. + +### Conflict-free release note entries for GitHub pull requests + +GitHub [PR #628](https://github.com/epics-base/epics-base/pull/628) + +This release replaces the developer-edited `documentation/RELEASE_NOTES.md` +source file in the EPICS tree with a process which generates that file from a +series of individual files added for each changeset in the release, thus +preventing merge conflicts when entries are added by many different pull +requests. + +For this new approach each pull request must add its own Markdown file to the +`documentation/new-notes` directory, using a unique filename. +When a release is made, all these files will be combined into a single +`RELEASE-.md` file and the `new-notes` directory emptied to prepare +for development of the next release. + +Developers can generate the `RELEASE_NOTES.md` file by running `make` in the +`documentation` directory, which will install the result in the `doc` top-level +directory along with the `RELEASE-.md` files describing older EPICS +releases going back to 3.15. +The `documentation/Makefile` provides some other targets which can also be +requested, but they require additional non-EPICS software such as Doxygen and +Sphinx to have been installed first. + +Between releases the generated `RELEASE_NOTES.md` file contains the text from +any `new-notes` files added to document changes already merged. +It also provides links to the older `RELEASE-.md` files, so it remains +the starting point for documentation on all release changes. + +Detailed instructions on creating new entries are provided in a `README.txt` +file in the `documentation/new-notes` directory. +The release-time process that generates a new `RELEASE-.md` file is +described in the developers' [Release Checklist](ReleaseChecklist.md). + +### Add support for `EPICS_DB_INCLUDE_PATH` to `dbLoadTemplate` + +GitHub [PR #636](https://github.com/epics-base/epics-base/pull/636) + +Allow finding the substitution file through a path in `EPICS_DB_INCLUDE_PATH` or +an additional parameter to the iocsh `dbLoadTemplate` command. + +### Expand the use of colour in the IOCs output + +This release includes various changes to iocsh.cpp and elsewhere to add and +expand the use of color: + +- When loading a startup script, the IOC Shell now displays comment lines in +blue, and uses bold to make command lines stand out from other text. + +- The `softIoc -v` output also uses the above color scheme for the commands it +prints. + +- The default IOC Shell prompt is now displayed in green; this color can be +modified in the `configure/CONFIG_SITE_ENV` file for all targets, or set for +a specific target by adding a `configure/os/CONFIG_SITE_ENV.` file. +The value of the `IOCSH_PS1` environment parameter in those files can use the +`ANSI_ENV_*` and `ANSI_*()` color macros found in errlog.h to configure the +appearance of the prompt. The C string literal concatenation syntax can be +used to construct the prompt string: + +```Makefile + IOCSH_PS1 = ANSI_ESC_RED "e" ANSI_ESC_YELLOW "p" ANSI_ESC_GREEN "i" \ + ANSI_ESC_CYAN "c" ANSI_BLUE("s") "> " +``` + +- More error messages printed by IOC Shell commands now appear in red, or use +the red `ERROR` prefix that was introduced in previous releases. + +- The word "Illegal" has been replaced with "Invalid" in several Shell error +messages. + +- The iocsh `var` command now shows the data type of the registered variables +as well as their values. + +### Documentation Updates + +The reference documentation for the [event](eventRecord.md) record type +has been updated to cover the use of named events which were added in Base +3.14.12.3 and 3.15.1. + +Documentation for CALC expression evaluation has been updated for format +enhancements and to add some missing operators. +The best documentation for these expressions can be found in the +[postfix.h](postfix_h.md) header in libCom, but both the +[calc](calcRecord.md) and [calcout](calcoutRecord.md) record reference +pages also cover the infix expressions supported. + +### Records calc, calcout and sub extended + +The record types calc, calcout and sub have been extended from 12 inputs +A - L to 21 inputs A - U. +The macro `CALCPERFORM_NARGS` reflects this change. +The new inputs can be used in calc links and access security as well. +The size of CALC and OCAL fields has been doubled to 160 chars. + +### Allow hex and octal strings in dbPut and dbGet + +It is now possible to convert hex and octal strings to integer fields +with `dbPut()`, `dbGet()` and related functions like the iocsh command +`dbpf` or through database links. + +Possible incompatibility: Up to now, leading `0`s have been ignored, +now they switch to octal mode. + +For backward compatibility, this behavior can be switched off, returning +to the old decimal only conversions, by setting the environment variable +`EPICS_DB_CONVERT_DECIMAL_ONLY` to `YES` (case insensitive) before `iocInit`. + +### `dfanout` improvements + +The [dfanout](dfanoutRecord.md) record now has invalid output handling with the usual fields +`IVOA` and `IVOV` just like many other output record types. + +The number of output links has also been increased from 8 to 16. + +### CA Client Library Enhancement + +GitHub [PR #711](https://github.com/epics-base/epics-base/pull/711) + +* Allow CA clients to determine a server's protocol version. + + Adds a call to the CA client API that allows a client to determine the + server's protocol minor version number. + This is needed to allow the ca-nameserver to report a server's protocol + version correctly to a client. + +* `ca_host_minor_protocol()` return for disconnected channels + + `ca_host_minor_protocol()` now explicitly returns `CA_UKN_MINOR_VERSION` + for a disconnected channel. + +### Add environment variable to opt out of POSIX Real-Time scheduling + +On POSIX systems, processes with real-time capabilities can opt out of using +Posix thread priority scheduling and memory locking. +Set `EPICS_ALLOW_POSIX_THREAD_PRIORITY_SCHEDULING=NO` to achieve this. + +### Avoid early expiration of timers on non-RTOS IOCs + +Previously the epicsTimer code rounded down user requested delays +by subtracting one half of the sleep "quantum". +On RTEMS and vxWorks, +this allowed periodic timers which expired on every tick. +However this also resulted in timers expiring slightly +[earlier than requested](https://github.com/epics-base/epics-base/issues/106). + +With [PR 744](https://github.com/epics-base/epics-base/pull/744) +rounding is only done for RTEMS and vxWorks, which still have tick timers. + +This affects several facilities which use epicsTimer, +including record delays. +For example, `calcout.ODLY` becomes more +[accurate](https://github.com/epics-base/epics-base/issues/106#issuecomment-1260232765) +on non-RTOS IOCs. + +### normativeTypes Module + +Changes to this module since the previous release: + +#### Release 6.0.2 + +- Fix potential NULL pointer dereference in `NTNDArray::getValueSize()` + +### pvAccess Module + +Changes to this module since the previous release: + +#### Release 7.1.8 + +- Compatible changes + - Capped the number and age of PVA beacons to avoid a resource leak. Beacons + older than 360 seconds will be destroyed automatically, new beacons will be + ignored if >=2048 exist already. + - Various Clang, MSVC and GCC compiler warnings cleaned up. + +### pvData Module + +Changes to this module since the previous release: + +#### Release 8.0.7 + +- Compatible changes + - Allow epics::pvData::Timer to be cancelled during callback execution. + - Clang compiler warnings cleaned up. + - Limit periodic timers to one catch-up after missing many events. + + +### pvaClient Module + +Changes to this module since the previous release: + +## Release 4.8.1 + +* Fix error message generation code. + + diff --git a/documentation/RELEASE-7.0.3.1.md b/documentation/RELEASE-7.0.3.1.md index 3f1180243..ed1998f72 100644 --- a/documentation/RELEASE-7.0.3.1.md +++ b/documentation/RELEASE-7.0.3.1.md @@ -56,7 +56,7 @@ A suggested form for IOC shell commands is: ### Relocatable Builds -Allows built trees to be copied or moved without invalidating RPATH entires. +Allows built trees to be copied or moved without invalidating RPATH entries. The `LINKER_USE_RPATH` Makefile variable (see `configure/CONFIG_SITE`) may be set to `YES`, `NO`, and a new third option `ORIGIN`. This is limited to diff --git a/documentation/RELEASE-7.0.5.md b/documentation/RELEASE-7.0.5.md index cab17a98d..afe1cab54 100644 --- a/documentation/RELEASE-7.0.5.md +++ b/documentation/RELEASE-7.0.5.md @@ -147,7 +147,7 @@ This also fixes [lauchpad bug #1714455](https://bugs.launchpad.net/bugs/1714455) declared in epicsString.h no longer accept octal escaped characters such as `\123` or `\41`. - The routine `epicsStrnEscapedFromRaw()` now generates hex - excaped characters for unprintable characters such as `\x1f`. + escaped characters for unprintable characters such as `\x1f`. - Hex escape character sequences `\xXX` must now contain exactly 2 hex digits. - An escape sequence `\0` now generates a zero byte in the raw string, but the other digits `1-9` should not appear after a back-slash. diff --git a/documentation/RELEASE-7.0.7.md b/documentation/RELEASE-7.0.7.md index 5ed0104f5..8c9043c58 100644 --- a/documentation/RELEASE-7.0.7.md +++ b/documentation/RELEASE-7.0.7.md @@ -117,7 +117,7 @@ with the TCP port number selected. DBD files generated by the `dbdExpand.pl` script are now sorted within each item type by the primary name of the item. The result should resolve any -issues with reproducable builds. No option is provided to prevent the sorting, +issues with reproducible builds. No option is provided to prevent the sorting, previously the order was essentially random and varied each time. ### `dbExpand.pl` sorts records by name diff --git a/documentation/RELEASE-7.0.8.md b/documentation/RELEASE-7.0.8.md index b9b071467..f8477a61b 100644 --- a/documentation/RELEASE-7.0.8.md +++ b/documentation/RELEASE-7.0.8.md @@ -35,7 +35,7 @@ record(bi, "bit1") { ### ANSI escapes in stderr -ANSI escape charactor sequences may now be printed to the stderr stream. +ANSI escape character sequences may now be printed to the stderr stream. These escapes will appear in logs captured from that stream. Tools which parse and/or render these logs may need to be adjusted to either strip out the escapes, or to translate them into markup. @@ -227,7 +227,7 @@ The pvDatabase module was updated to version 4.7.1: `_[distributor=group:;set:;trigger:;updates:;mode:]` - The plugin parameters are optional and are described bellow: + The plugin parameters are optional and are described below: - group: this parameter indicates a group that client application belongs to (default value: "default"); groups of clients are completely independent of each other diff --git a/documentation/RELEASE-7.0.9.md b/documentation/RELEASE-7.0.9.md index 015f50c06..71883905d 100644 --- a/documentation/RELEASE-7.0.9.md +++ b/documentation/RELEASE-7.0.9.md @@ -25,7 +25,7 @@ although it doesn't currently cover the new processes added to epics-base. Much of the documentation generated from .dbd.pod files at build time is now also being converted into MarkDown (.md) files and installed into the top-level `doc` directory. Some users might find it quicker to look up information about a -record type by opening these files in a text editor intead of opening a browser +record type by opening these files in a text editor instead of opening a browser and loading the HTML versions or finding and opening the files from the EPICS Documentation site. @@ -97,7 +97,7 @@ record("#", "unwanted") {} ### Only keep readline history for interactive sessions -Previously, all IOCsh commands were persisited in the libreadline history +Previously, all IOCsh commands were persisted in the libreadline history (when readline support is included). Going forward, only interactive commands are saved. @@ -111,7 +111,7 @@ already be conditionally casting to/from the appropriate type. ### Fix issues with `_FORTIFY_SOURCE=3` -This release fixes the false positives failures whhen building with `_FORTIFY_SOURCE` level 3. +This release fixes the false positives failures when building with `_FORTIFY_SOURCE` level 3. The override introduced in 7.0.8.1 has been removed. ### Other diff --git a/documentation/ReleaseChecklist.html b/documentation/ReleaseChecklist.html deleted file mode 100644 index 4ef9d98d9..000000000 --- a/documentation/ReleaseChecklist.html +++ /dev/null @@ -1,492 +0,0 @@ - - - - - - EPICS Release Procedures & Checklist - - - - -

EPICS Base Release Procedures & Checklist

- -

This document describes the procedures and provides a checklist of tasks -that should be performed when creating production releases of EPICS Base.

- -

The Release Process

- -

We used to have one written down here, but we weren't following it very -closely so now the decision to make a new release is taken during the Core -Developers bi-weekly meetings in an informal manner. The steps detailed below -were written to remind Andrew (or anyone else who does the release) about -everything that has to be done since it's so easy to miss steps.

- -

Roles

- -

The following roles are used below:

- -
-
Release Manager
-
Responsible for managing and tagging the release
-
Core Developers
-
Responsible for maintaining the EPICS software
-
Website Editors
-
Responsible for the EPICS websites
-
- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
CheckWhoDescription
Preparing for a release
 Release ManagerNotify core developers about the upcoming release and ask about any - remaining tasks that must be finished.
 All developersCheck the bug tracker for any outstanding items and handle - appropriately.
 Release ManagerSet a Feature Freeze date, by which time all Git branches for - enhancements and new functionality should have been merged. After this - date, commits and merges should only be made to fix problems that show - up during testing.
 Release Manager
- & all developers
Request that documentation be updated and information about new - features be added before the release date: - -
 Release ManagerReview and update this checklist for the upcoming release. - Update the release version number in the tags and messages below.
Testing
 Platform DevelopersRun the internal test programs on all appropriate platforms.
 Platform DevelopersCheck that all makeBaseApp templates build and run properly, all - xxxApp and xxxBoot types and any internal options, e.g. - setting STATIC_BUILD=YES or using a different - INSTALL_LOCATION in configure/CONFIG_SITE.
 Release ManagerCheck that documentation has been updated: - -
- Release Approval
Core DevelopersReach a consensus that the software is ready to release.
Creating the final release version
Release Manager -

For each external submodule to be tagged

-
    -
  1. cd base-7.0/modules/<module>; git grep UNRELEASED - and insert the submodule's version number into any doxygen - annotations that have a @since UNRELEASED comment. - Commit (don't push yet).
  2. - -
  3. Check that the submodule's Release Notes have been updated to - cover all changes; add missing items as necessary, and set the - module version number and release date if appropriate.
    - Commit the changes to the submodule's Notes file (don't push).
  4. - -
  5. Copy the new submodule version number and Release Notes entries - into a new file named module-release in the - base-7.0/documentation/new-notes directory.
  6. - -
  7. Edit the module's release version file - configure/CONFIG_module_VERSION and the - Doxyfiles in the top-level and/or documentation - directories. In these, set DEVELOPMENT_FLAG=0 and remove - -dev from the PROJECT_NUMBER string. Commit these - changes (don't push): -
    - git commit -m 'Final commit for <submodule-version>' -
    -
  8. - -
  9. Tag the submodule: -
    - git tag -m 'ANJ: Tag for EPICS 7.0.9.1' <submodule-version> -
    -
  10. - -
  11. Generate documentation for modules with release_notes.dox - files. Prepare to update the github-pages website as follows: -
    - cd base-7.0/modules/<module>/documentation
    - make commit
    - git push --force upstream gh-pages -
    - Q: Delay this git push until later?
  12. - -
  13. Update the Git submodule on the Base-7.0 branch to the - newly-tagged version, check the module's status matches the tag: -
    - cd base-7.0/modules
    - git add <module>
    - git submodule status --cached -
    - Don't commit the submodule updates yet. -
  14. - -
  15. Edit the module's release version file - configure/CONFIG_module_VERSION and its top-level - Doxyfile; increment the MAINTENANCE_VERSION, set - the DEVELOPMENT_FLAG value to 1, and update the - PROJECT_NUMBER string, appending -dev to the new - module version number. Commit changes.
  16. - -
  17. Push commits and the new tag to the submodule's GitHub repository - (assumed to be the upstream remote): -
    - cd base-7.0/modules/<module>
    - git push --follow-tags upstream master -
    -
  18. - -
Release Manager -

After all submodules have been updated:

-
    - -
  1. Commit the submodule updates which were added for each submodule - in step 7 above to the 7.0 branch (don't push): -
    - cd base-7.0/modules
    - git commit -m "Update git submodules for release" -
  2. - -
  3. Make sure that the output from - git submodule status --cached only shows the appropriate - version tags in the right-most parenthesized column with no - -n-gxxxxxxx suffix.
  4. - -
  5. Add and commit the new Release Note entry files that were created - for each submodule in step 3 above (don't push): -
    - cd base-7.0/documentation
    - git add new-notes
    - git commit -m "Add submodule release note entries" -
  6. - -
-
Release Manager -

In the main epics-base repository

-
    -
  1. cd base-7.0; git grep UNRELEASED and insert the release - version to any doxygen annotations that have a - @since UNRELEASED comment. Commit (don't push).
  2. - -
  3. Edit the main EPICS Base version file and the built-in module - version files: -
      -
    • configure/CONFIG_BASE_VERSION
    • -
    • configure/CONFIG_LIBCOM_VERSION
    • -
    • configure/CONFIG_CA_VERSION
    • -
    • configure/CONFIG_DATABASE_VERSION
    • -
    -
  4. - -
  5. Version numbers should be set according to the level of changes - made since the last release. Note that the - MAINTENANCE_VERSION or PATCH_LEVEL value will have - been incremented immediately after the previous release tag was - applied, so don't double-increment them. Set all - DEVELOPMENT_FLAG values to 0 and set the - EPICS_DEV_SNAPSHOT to an empty string (no quotes).
  6. - -
  7. Commit the above changes (don't push): -
    - cd base-7.0
    - git add configure/CONFIG_*_VERSION
    - git commit -m "Set core version numbers for release" -
  8. - -
  9. When EPICS_DEV_SNAPSHOT is empty because a release is - being created, the documentation/Makefile supports a build - target release for creating a new release notes file - documentation/RELEASE-version.md from the Markdown - files in the documentation/new-notes directory. When run, - it copies the notes entries from all the new-notes/*.md - files, then deletes the files and prepares a Git commit to apply - those changes permanently to the repository.

    - -

    Run these commands to generate the RELEASE-7.0.9.1.md - file and remove the individual release note entry files:

    - -
    - cd base-7.0/documentation
    - make -
  10. - -
  11. The make release command add some changes into the Git - index but didn't commit them. These commands let you check what - was done and commit the result (don't push yet!): - -
    - git status
    - git diff --staged
    - git commit -m "Generate RELEASE-7.0.9.1.md notes file" -
    - - To undo those Git actions and confirm that happened, run these: - -
    - make unrelease
    - git status -
  12. -
-
Release ManagerTag the epics-base module in Git: -
- cd base-7.0
- git tag -m 'ANJ: Tagged for release' R7.0.9.1 -
-

Don't push to GitHub yet.

-
Release Manager

After tagging the release

- Edit the main EPICS Base version file and the built-in module version - files: -
    -
  • configure/CONFIG_BASE_VERSION
  • -
  • configure/CONFIG_LIBCOM_VERSION
  • -
  • configure/CONFIG_CA_VERSION
  • -
  • configure/CONFIG_DATABASE_VERSION
  • -
-

Version numbers should be set for the next expected patch/maintenance - release by incrementing the MAINTENANCE_VERSION or PATCH_LEVEL value - in each file. Set all DEVELOPMENT_FLAG values to 1 and - EPICS_DEV_SNAPSHOT to "-DEV".

-

Set up the headings in the Release Notes for the next release - version number and restore the warning about this being an unreleased - version of EPICS.

-

Commit these changes (don't push).

-
Release ManagerExport the tagged version into a tarfile. The make-tar.sh - script generates a gzipped tarfile directly from the tag, excluding the - files and directories that are only used for continuous integration: -
- cd base-7.0
- ./.tools/make-tar.sh R7.0.9.1 ../base-7.0.9.1.tar.gz base-7.0.9.1/ -
- Create a GPG signature file of the tarfile as follows: -
- cd ..
- gpg --armor --sign --detach-sig base-7.0.9.1.tar.gz -
-
Release ManagerTest the tar file by extracting its contents and building it on at - least one supported platform. If this succeeds the commits and new git - tag can be pushed to the GitHub repository's 7.0 branch (assumed to be - the upstream remote): -
- git push --follow-tags upstream 7.0 -
-
Publish to epics.anl.gov
Website EditorCopy the tarfile and its signature to the Base download area of the - website.
Website EditorAdd the new release tar file to the website Base download index - page.
Website EditorCreate or update the website subdirectory that holds the release - documentation, and copy in the files to be published with this - release version.
Website EditorUpdate the webpage for the new release with links to the release - documents and tar file.
Website EditorLink to the release webpage from other relevent areas of the - website - update front page and sidebars.
Website EditorAdd an entry to the website News page, linking to the new version - webpage.
Publish to epics-controls.org
Website EditorUpload the tar file and its .asc signature file to the - epics-controls web-server. -
- scp base-7.0.9.1.tar.gz base-7.0.9.1.tar.gz.asc epics-controls:download/base
-
-
Website Editor

Follow instructions on - - Add a page for a new release to create a new release webpage (not - required for a patch release, just edit the existing page). Update the - TablePress "Point Releases" table and add the new download, and adjust - the Html Snippet for the series download.

-

Not covered in those instructions: Go to Posts, find a previous - release and use "Duplicate Post", then edit the result and publish it. - This generates the News item. -

Publish to GitHub
Release ManagerGo to the GitHub - - Create release from tag R7.0.9.1 page. - Upload the tar file and its .asc signature file to the new - GitHub release page, or just drag-n-drop them into the page. - Copy/paste the text from the previous release and edit. Submit.
Release ManagerWe used to close out bug reports in Launchpad at release-time, this - would be the time to do that if we have an equivalent on GitHub.
Make Announcement
Release ManagerAnnounce the release on the tech-talk mailing list.
-
- - diff --git a/documentation/ReleaseChecklist.md b/documentation/ReleaseChecklist.md new file mode 100644 index 000000000..7fefba00b --- /dev/null +++ b/documentation/ReleaseChecklist.md @@ -0,0 +1,390 @@ +# EPICS Base Release Procedures & Checklist + +This document describes the procedures and provides a checklist of tasks +that should be performed when creating production releases of EPICS +Base. + +## The Release Process + +The decision to make a new release is taken during the +Core Developers bi-weekly meetings in an informal manner. The steps +detailed below were written to remind Andrew (or whoever does +the release) exactly what has to be done, since it's so easy to +miss steps. + +### Roles + +The following roles are used below: + +**Release Manager** +Responsible for managing and tagging the release + +**Core Developers** +Responsible for maintaining the EPICS software + +**Website Editors** +Responsible for the EPICS websites + + ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
WhoDescription
Preparing for a release
Release ManagerNotify core developers about the upcoming release and ask about any +remaining tasks that must be finished.
All developersCheck the bug tracker for any outstanding items and handle +appropriately.
Release ManagerSet a Feature Freeze date, by which time all Git branches for +enhancements and new functionality should have been merged. After this +date, commits and merges should only be made to fix problems that show +up during testing.
Release Manager
+& all developers
Request that documentation be updated and information about new +features be added before the release date: +
Release ManagerReview and update this checklist for the upcoming release. Update +the release version number in the tags and messages below.
Testing
Platform DevelopersRun the internal test programs on all appropriate platforms.
Platform DevelopersCheck that all makeBaseApp templates build and run properly, all +xxxApp and xxxBoot types and any internal options, +e.g. setting STATIC_BUILD=YES or using a different +INSTALL_LOCATION in configure/CONFIG_SITE.
Release ManagerCheck that documentation has been updated: +
Release Approval
Core DevelopersReach a consensus that the software is ready to release.
Creating the final release version
Release Manager

For each external +submodule to be tagged

+
    +
  1. cd base-7.0/modules/<module>; git grep UNRELEASED +and insert the submodule's version number into any doxygen annotations +that have a @since UNRELEASED comment. Commit (don't push +yet).
  2. +
  3. Check that the submodule's Release Notes have been updated to cover +all changes; add missing items as necessary, and set the module version +number and release date if appropriate.
    +Commit the changes to the submodule's Notes file (don't push).
  4. +
  5. Copy the new submodule version number and Release Notes entries into +a new file named +module-release +in the base-7.0/documentation/new-notes directory.
  6. +
  7. Edit the module's release version file +configure/CONFIG_module_VERSION +and the Doxyfiles in the top-level and/or documentation +directories. In these, set DEVELOPMENT_FLAG=0 and remove +-dev from the PROJECT_NUMBER string. Commit +these changes (don't push):

    +
    + git commit -m 'Final commit for <submodule-version>' +
  8. +
  9. Tag the submodule:

    +
    + git tag -m 'ANJ: Tag for EPICS 7.0.10' <submodule-version> +
  10. +
  11. Generate documentation for modules with +release_notes.dox files. Prepare to update the github-pages +website as follows:

    +
    + cd base-7.0/modules/<module>/documentation
    +make commit
    +git push --force upstream gh-pages +
    +

    Q: Delay this git push until later?

  12. +
  13. Update the Git submodule on the Base-7.0 branch to the +newly-tagged version, check the module's status matches the tag:

    +
    + cd base-7.0/modules
    +git add <module>
    +git submodule status --cached +
    +

    Don't commit the submodule updates yet.

  14. +
  15. Edit the module's release version file +configure/CONFIG_module_VERSION +and its top-level Doxyfile; increment the +MAINTENANCE_VERSION, set the DEVELOPMENT_FLAG +value to 1, and update the PROJECT_NUMBER string, appending +-dev to the new module version number. Commit changes.
  16. +
  17. Push commits and the new tag to the submodule's GitHub repository +(assumed to be the upstream remote):

    +
    + cd base-7.0/modules/<module>
    +git push --follow-tags upstream master +
  18. +
Release Manager

After all submodules +have been updated:

+
    +
  1. Commit the submodule updates which were added for each submodule +in step 7 above to the 7.0 branch (don't push):

    +
    + cd base-7.0/modules
    +git commit -m "Update git submodules for release" +
  2. +
  3. Make sure that the output from +git submodule status --cached only shows the appropriate +version tags in the right-most parenthesized column with no +-n-gxxxxxxx +suffix.
  4. +
  5. Add and commit the new Release Note entry files that were created +for each submodule in step 3 above (don't push):

    +
    + cd base-7.0/documentation
    +git add new-notes
    +git commit -m "Add submodule release note entries" +
  6. +
Release Manager

In the main epics-base +repository

+
    +
  1. cd base-7.0; git grep UNRELEASED and insert the release +version to any doxygen annotations that have a +@since UNRELEASED comment. Commit (don't push).
  2. +
  3. Edit the main EPICS Base version file and the built-in module +version files: +
      +
    • configure/CONFIG_BASE_VERSION
    • +
    • configure/CONFIG_LIBCOM_VERSION
    • +
    • configure/CONFIG_CA_VERSION
    • +
    • configure/CONFIG_DATABASE_VERSION
    • +
  4. +
  5. Version numbers should be set according to the level of changes made +since the last release. Note that the MAINTENANCE_VERSION +or PATCH_LEVEL value will have been incremented immediately +after the previous release tag was applied, so don't double-increment +them. Set all DEVELOPMENT_FLAG values to 0 and set the +EPICS_DEV_SNAPSHOT to an empty string (no quotes).
  6. +
  7. Commit the above changes (don't push):

    +
    + cd base-7.0
    +git add configure/CONFIG_*_VERSION
    +git commit -m "Set core version numbers for release" +
  8. +
  9. When EPICS_DEV_SNAPSHOT is empty because a release +is being created, the documentation/Makefile supports a +build target release for creating a new release notes file +documentation/RELEASE-version.md +from the Markdown files in the documentation/new-notes +directory. When run, it copies the notes entries from all the +new-notes/*.md files, then deletes the files and prepares a +Git commit to apply those changes permanently to the repository.

    +

    Run these commands to generate the RELEASE-7.0.10.md +file and remove the individual release note entry files:

    +
    + cd base-7.0/documentation
    +make release +
  10. +
  11. The make release command add some changes into the +Git index but didn't commit them. These commands let you check what was +done and commit the result (don't push yet!):

    +
    + git status
    +git diff --staged
    +git commit -m "Generate RELEASE-7.0.10.md notes file" +
    +

    To undo those Git actions and confirm that happened, run these:

    +
    + make unrelease
    +git status +
  12. +
Release ManagerTag the epics-base module in Git: +
+ cd base-7.0
+git tag -m 'ANJ: Tagged for release' R7.0.10 +
+

Don't push to GitHub yet.

Release Manager

After tagging the release

+Edit the main EPICS Base version file and the built-in module version +files: +
    +
  • configure/CONFIG_BASE_VERSION
  • +
  • configure/CONFIG_LIBCOM_VERSION
  • +
  • configure/CONFIG_CA_VERSION
  • +
  • configure/CONFIG_DATABASE_VERSION
  • +
+

Version numbers should be set for the next expected patch/maintenance +release by incrementing the MAINTENANCE_VERSION or PATCH_LEVEL value in +each file. Set all DEVELOPMENT_FLAG values to 1 and +EPICS_DEV_SNAPSHOT to "-DEV".

+

Commit these changes (don't push).

Release ManagerExport the tagged version into a tarfile. The +make-tar.sh script generates a gzipped tarfile directly +from the tag, excluding the files and directories that are only used for +continuous integration: +
+ cd base-7.0
+./.tools/make-tar.sh R7.0.10 ../base-7.0.10.tar.gz base-7.0.10/ +
+Create a GPG signature file of the tarfile as follows: +
+ cd ..
+gpg --armor --sign --detach-sig base-7.0.10.tar.gz +
Release ManagerTest the tar file by extracting its contents and building it on at +least one supported platform. If this succeeds the commits and new git +tag can be pushed to the GitHub repository's 7.0 branch (assumed to be +the upstream remote): +
+ git push --follow-tags upstream 7.0 +
Publish to epics.anl.gov
Website EditorCopy the tarfile and its signature to the Base download area of the +website.
Website EditorAdd the new release tar file to the website Base download index +page.
Website EditorCreate or update the website subdirectory that holds the release +documentation, and copy in the files to be published with this release +version.
Website EditorUpdate the webpage for the new release with links to the release +documents and tar file.
Website EditorLink to the release webpage from other relevant areas of the website +- update front page and sidebars.
Website EditorAdd an entry to the website News page, linking to the new version +webpage.
Publish to epics-controls.org
Website EditorUpload the tar file and its .asc signature file to the +epics-controls web-server. +
+ scp base-7.0.10.tar.gz base-7.0.10.tar.gz.asc epics-controls:download/base
+
Website Editor

Follow instructions on + +Add a page for a new release +to create a new release webpage (not +required for a patch release, just edit the existing page). Update the +TablePress "Point Releases" table and add the new download, and adjust +the Html Snippet for the series download.

+

Not covered in those instructions: Go to Posts, find a previous +release and use "Duplicate Post", then edit the result and publish it. +This generates the News item.

Publish to GitHub
Release ManagerGo to the GitHub + +Create +release from tag R7.0.10 page. Upload the tar file and its +.asc signature file to the new GitHub release page, or just +drag-n-drop them into the page. Copy/paste the text from the previous +release and edit. Submit.
Release ManagerWe used to close out bug reports in Launchpad at release-time, this +would be the time to do that if we have an equivalent on GitHub.
Make Announcement
Release ManagerAnnounce the release on the tech-talk mailing list.
diff --git a/documentation/index.rst b/documentation/index.rst index be6f2d3b2..a84446ba7 100644 --- a/documentation/index.rst +++ b/documentation/index.rst @@ -13,6 +13,7 @@ EPICS Base Documentation README RELEASE_NOTES + ACF-Language .. toctree:: :maxdepth: 2 diff --git a/documentation/new-notes/PR-518.md b/documentation/new-notes/PR-518.md deleted file mode 100644 index ececf7cb0..000000000 --- a/documentation/new-notes/PR-518.md +++ /dev/null @@ -1,7 +0,0 @@ -### Reduce symbol and macro pollution from epicsAtomic.h on WIN32 - -`epicsAtomic.h` no longer pulls in as many unneeded declarations and macros from -`windows.h`. Prior to this change, including `epicsAtomic.h` at the wrong time -could result in unexpected compiler errors. Due to the nature of `windows.h`, -some unneeded declarations are still pulled in, however the number is greatly reduced. -Code that needs these declarations should explicitly include `windows.h` before `epicsAtomic.h`. diff --git a/documentation/new-notes/PR-558.md b/documentation/new-notes/PR-558.md deleted file mode 100644 index 17f8a90cf..000000000 --- a/documentation/new-notes/PR-558.md +++ /dev/null @@ -1,23 +0,0 @@ -### New `afterIocRunning` IOC Shell Command Added - -This release incorporates [PR #558](https://github.com/epics-base/epics-base/pull/558) which added a new IOC shell command `afterIocRunning`. This command allows startup scripts to schedule arbitrary commands to be executed automatically after the IOC initialization phase (`iocInit`). - -`afterIocRunning` allows you to write better-structured IOC shell files to include in your startup scripts without tracking where `iocInit` is located (and how IOC is deployed) e.g.: -- to achieve the best maintainability (e.g. encapsulation of the context into one file), -- to improve writing boot sequences, -- to improve IOC startup flexibility and scripting capabilities, -- it replaces the community [`afterInit`](https://github.com/paulscherrerinstitute/iocsh_utilities/blob/master/afterInit.c) and [`doAfterIocInit`](https://github.com/epics-modules/std/blob/master/stdApp/src/delayCmd.cpp) IOC shell commands, -- community usage examples: - - [`pf4filters.iocsh`](https://github.com/epics-modules/optics/blob/master/opticsApp/iocsh/pf4filters.iocsh) - enable/disable with a single comment ([full description](https://github.com/epics-base/epics-base/pull/558#issuecomment-2430057167)) - - [ALS-U autosave managment](https://github.com/epics-base/epics-base/pull/558#issuecomment-2430447220) - -#### Features - -- Define commands that run after IOC initialization completes. -- Executes following `iocInit` and `autosave` initialization (important for proper PV configuration). -- Supports any valid IOC shell command as an argument. -- Example usages: - - `afterIocRunning "dbpf "` - - `afterIocRunning "date"` - - `afterIocRunning "dbpf $(P)EvtClkSource-Sel 'Upstream (fanout)'"` - - `afterIocRunning "dbpf $(P)Enable-Sel Enabled"` diff --git a/documentation/new-notes/PR-587.md b/documentation/new-notes/PR-587.md deleted file mode 100644 index e63f1b871..000000000 --- a/documentation/new-notes/PR-587.md +++ /dev/null @@ -1,5 +0,0 @@ -### fdManager file descriptor limit removed - -In order to support file descriptors above 1023, fdManager now uses -`poll()` instead of `select()` on all architectures that support it -(Linux, MacOS, Windows, newer RTEMS). diff --git a/documentation/new-notes/PR-592.md b/documentation/new-notes/PR-592.md deleted file mode 100644 index 718fe1e77..000000000 --- a/documentation/new-notes/PR-592.md +++ /dev/null @@ -1,7 +0,0 @@ -### New `dbServerStats()` API for iocStats - -A new routine provides the ability to request channel and client counts from -named server layers that implement the `stats()` method, or to get a summary -of the counts from all registered server layers. A preprocessor macro -`HAS_DBSERVER_STATS` macro is defined in the `dbServer.h` header file to -simplify code that needs to support older versions of Base as well. diff --git a/documentation/new-notes/PR-599.md b/documentation/new-notes/PR-599.md deleted file mode 100644 index 91a67e683..000000000 --- a/documentation/new-notes/PR-599.md +++ /dev/null @@ -1,4 +0,0 @@ -### epicsExport simplifications - -`epicsExportAddress()`, `epicsExportRegistrar()` and `epicsRegisterFunction()` -no longer require to be wrapped in `extern "C" { }` in C++ code. diff --git a/documentation/new-notes/PR-603.md b/documentation/new-notes/PR-603.md deleted file mode 100644 index 72a96e178..000000000 --- a/documentation/new-notes/PR-603.md +++ /dev/null @@ -1,14 +0,0 @@ -### Support for multiline strings in iocsh files - -GitHub [PR #603](https://github.com/epics-base/epics-base/pull/603) - -This update introduces support for multiline strings in IOC shell (iocsh) files. -Previously, string values in iocsh files were limited to a single line, making -it difficult to include longer or formatted text. With this change, users can -now define strings that span multiple lines, improving readability and -flexibility when configuring IOC shell scripts. - -To create a multiline string, end a line with a backslash (`\`). The following -line, including any leading whitespace, will be joined to the previous line. -If the backslash is immediately followed by any character other than a newline, -it will not be treated as a multiline continuation. diff --git a/documentation/new-notes/PR-613.md b/documentation/new-notes/PR-613.md deleted file mode 100644 index 74a7a0d0d..000000000 --- a/documentation/new-notes/PR-613.md +++ /dev/null @@ -1,4 +0,0 @@ -### Enhancement to IOC `dbgrep` command - -`dbgrep` now takes an optional second string argument consisting of a list of field names -separated by spaces, e.g. `dbgrep "*PRESSURE*", "VAL DESC"` diff --git a/documentation/new-notes/PR-626.md b/documentation/new-notes/PR-626.md deleted file mode 100644 index 2df0a077d..000000000 --- a/documentation/new-notes/PR-626.md +++ /dev/null @@ -1,5 +0,0 @@ -*** Add `dbglob` to replace `dbgrep` - -A new IOC shell command, `dbglob` has been added, with `dbgrep` becoming -an alias of this new function, with the intent of deprecating it in a -future release. diff --git a/documentation/new-notes/PR-628.md b/documentation/new-notes/PR-628.md deleted file mode 100644 index 8f2ae55eb..000000000 --- a/documentation/new-notes/PR-628.md +++ /dev/null @@ -1,33 +0,0 @@ -### Conflict-free release note entries for GitHub pull requests - -GitHub [PR #628](https://github.com/epics-base/epics-base/pull/628) - -This release replaces the developer-edited `documentation/RELEASE_NOTES.md` -source file in the EPICS tree with a process which generates that file from a -series of individual files added for each changeset in the release, thus -preventing merge conflicts when entries are added by many different pull -requests. - -For this new approach each pull request must add its own Markdown file to the -`documentation/new-notes` directory, using a unique filename. -When a release is made, all these files will be combined into a single -`RELEASE-.md` file and the `new-notes` directory emptied to prepare -for development of the next release. - -Developers can generate the `RELEASE_NOTES.md` file by running `make` in the -`documentation` directory, which will install the result in the `doc` top-level -directory along with the `RELEASE-.md` files describing older EPICS -releases going back to 3.15. -The `documentation/Makefile` provides some other targets which can also be -requested, but they require additional non-EPICS software such as Doxygen and -Sphinx to have been installed first. - -Between releases the generated `RELEASE_NOTES.md` file contains the text from -any `new-notes` files added to document changes already merged. -It also provides links to the older `RELEASE-.md` files, so it remains -the starting point for documentation on all release changes. - -Detailed instructions on creating new entries are provided in a `README.txt` -file in the `documentation/new-notes` directory. -The release-time process that generates a new `RELEASE-.md` file is -described in the `documentation/ReleaseChecklist.html` file. diff --git a/documentation/new-notes/PR-636.md b/documentation/new-notes/PR-636.md deleted file mode 100644 index 79ecd2248..000000000 --- a/documentation/new-notes/PR-636.md +++ /dev/null @@ -1,6 +0,0 @@ -### Add support for EPICS_DB_INCLUDE_PATH to dbLoadTemplate - -GitHub [PR #636](https://github.com/epics-base/epics-base/pull/636) - -Allow finding the substitution file using path in `EPICS_DB_INCLUDE_PATH` or -an additional parameter to `dbLoadTemplate`. diff --git a/documentation/new-notes/PR-644.md b/documentation/new-notes/PR-644.md deleted file mode 100644 index d30bb2018..000000000 --- a/documentation/new-notes/PR-644.md +++ /dev/null @@ -1,32 +0,0 @@ -### Expand the use of colour in the IOCs output - -This release includes various changes to iocsh.cpp and elsewhere to add and -expand the use of color: - -- When loading a startup script, the IOC Shell now displays comment lines in -blue, and uses bold to make command lines stand out from other text. - -- The `softIoc -v` output also uses the above color scheme for the commands it -prints. - -- The default IOC Shell prompt is now displayed in green; this color can be -modified in the `configure/CONFIG_SITE_ENV` file for all targets, or set for -a specific target by adding a `configure/os/CONFIG_SITE_ENV.` file. -The value of the `IOCSH_PS1` environment paremeter in those files can use the -`ANSI_ENV_*` and `ANSI_*()` color macros found in errlog.h to configure the -appearance of the prompt. The C string literal concatenation syntax can be -used to construct the prompt string: - -```Makefile - IOCSH_PS1 = ANSI_ESC_RED "e" ANSI_ESC_YELLOW "p" ANSI_ESC_GREEN "i" \ - ANSI_ESC_CYAN "c" ANSI_BLUE("s") "> " -``` - -- More error messages printed by IOC Shell commands now appear in red, or use -the red `ERROR` prefix that was introduced in previous releases. - -- The word "Illegal" has been replaced with "Invalid" in several Shell error -messages. - -- The iocsh `var` command now shows the data type of the registered variables -as well as their values. diff --git a/documentation/new-notes/README.txt b/documentation/new-notes/README.txt index e95f559af..f866e0ddc 100644 --- a/documentation/new-notes/README.txt +++ b/documentation/new-notes/README.txt @@ -34,7 +34,7 @@ where nnn is the number of the pull request. If you haven't created the pull request yet you can use the number from a related GitHub issue, or use some other name, then rename and push it after the PR has been created. -The file should start with a level-3 Markdown title for the entry, like this: +The file *must* start with a level-3 Markdown title for the entry, like this: ### Conflict-free release note entries for GitHub pull requests @@ -46,6 +46,9 @@ The file should start with a level-3 Markdown title for the entry, like this: (followed by a blank line to separate it from the next paragraph), or a link to the PR may be integrated into the text that follows. * Use blank lines between paragraphs of text, and code-blocks for examples. + * I recommend using [semantic line-breaks](https://sembr.org/) in Markdown + files, it makes editing easier and reduces the number of lines that change + in most commits. This README.txt file isn't formatted as Markdown. Release note entries are not intended to provide full documentation of major features. For small features or changes though, they may provide all the diff --git a/modules/ca/src/client/CAref.html b/modules/ca/src/client/CAref.html index 7b6ff143f..9b5c95bb3 100644 --- a/modules/ca/src/client/CAref.html +++ b/modules/ca/src/client/CAref.html @@ -103,7 +103,7 @@ in the file LICENSE that is included with this distribution.