[ANNOUNCE] CMake 3.21.0-rc2 is ready for testing

2021-06-30 Thread Tom Osika
I am proud to announce the second CMake 3.21 release candidate.
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.21

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.21/release/3.21.html

Some of the more significant changes in CMake 3.21 are:

* CMake learned to support "HIP" as a first-class language that can be
  enabled via the "project()" and "enable_language()" commands.

* The "Visual Studio 17 2022" generator was added.  This is
  experimental and based on "Visual Studio 2022 Preview 1.1" because
  this version of VS has not been released.

* The Makefile Generators and the "Ninja" generator learned to add
  linker launcher tools along with the linker for "C", "CXX", "OBJC",
  and "OBJCXX" languages. See the "CMAKE__LINKER_LAUNCHER"
  variable and "_LINKER_LAUNCHER" target property for details.

* "C_STANDARD", "OBJC_STANDARD", and the "Compile Features"
  functionality gained support for C17 and C23.

* "cmake(1)" gained the "--toolchain " command-line
  option to specify a toolchain file.

* Messages printed to a terminal now may be colored by message type.

* The Fujitsu compiler is now supported using compiler id "Fujitsu" in
  traditional ("Trad") mode, and compiler id "FujitsuClang" in "Clang"
  mode.

* The "add_custom_command()" command "DEPFILE" option may now use
  "generator expressions", is now supported by Visual Studio Generators
  for VS 2012 and above, and is now supported by the "Xcode" generator.

* The "add_custom_command(TARGET)" command (for Build Events) gained
  support for resolving target-dependent generator expressions.

* The "install(TARGETS)" command gained new "RUNTIME_DEPENDENCIES" and
  "RUNTIME_DEPENDENCY_SET" arguments, which can be used to install
  runtime dependencies using "file(GET_RUNTIME_DEPENDENCIES)".

* A new "TARGET_RUNTIME_DLLS" generator expression was added.

* "ctest(1)" gained a "--output-junit" option to write test results to
  a JUnit XML file.

* The "ctest_build()" command gained a "PARALLEL_LEVEL" option.

* "ARMClang" cpu/arch compile and link flags are no longer added
  automatically based on the "CMAKE_SYSTEM_PROCESSOR" variable or the
  undocumented "CMAKE_SYSTEM_ARCH" variable. They must be specified
  explicitly.  See policy "CMP0123".

* The "foreach()" command now isolates loop variables in the loop
  scope. See policy "CMP0124" for details.


CMake 3.21 Release Notes


Changes made since CMake 3.20 include the following.


New Features



Presets
---

* "cmake-presets(7)" gained support for specifying the install prefix
  in a configure preset.

* "cmake-presets(7)" gained support for conditional enabling of
  presets.

* "cmake-presets(7)" gained support for a "${hostSystemName}" macro.

* "cmake-presets(7)" gained support for omitting the "generator" and
  "binaryDir" fields.


Generators
--

* The Makefile Generators and the "Ninja" generator learned to add
  linker launcher tools along with the linker for "C", "CXX", "OBJC",
  and "OBJCXX" languages. See the "CMAKE__LINKER_LAUNCHER"
  variable and "_LINKER_LAUNCHER" target property for details.

* The "Visual Studio 17 2022" generator was added.  This is
  experimental and based on "Visual Studio 2022 Preview 1.1" because
  this version of VS has not been released.


Languages
-

* CMake learned to support "HIP" as a first-class language that can be
  enabled via the "project()" and "enable_language()" commands.

* "C_STANDARD", "OBJC_STANDARD", and the "Compile Features"
  functionality gained support for C17 and C23.

* Source file extensions ".ixx" and ".cppm" are now treated as C++.


Command-Line


* "cmake(1)" gained the "--install-prefix " command-line option
  to specify the location of the install prefix.

* "cmake(1)" gained the "--toolchain " command-line
  option to specify a toolchain file.

* "cmake(1)" "-E capabilities" output, for some generators, may now
  contain a "supportedPlatforms" field listing platforms known to be
  supported in "CMAKE_GENERATOR_PLATFORM".

* Messages printed to a terminal now may be colored by message type.


Compilers
-

* The Fujitsu compiler is now supported using compiler id "Fujitsu" in
  traditional ("Trad") mode, and compiler id "FujitsuClang" in "Clang"
  mode.


Platforms
-

* CMake now supports the MSYS runtime environment, much like CYGWIN.


File-Based API
--

* The "cmake-file-api(7)" "codemodel" version 2 "version" field has
  been updated to 2.3.

* The "cmake-file-api(7)" "codemodel" version 2 gained a new
  "directory" object containing directory-level information. This
  includes a list of installers generated by the "install()" command.


Commands


* The "add_custom_command()" command "DEPFILE" option may now use
  "generator expressions", is now supported by Visual Studio Generators
  for VS 2012 and above, and is now supported by th

Re: Progress is good for us but bad for documentation

2021-06-30 Thread Frederik Schwarzer

Hi everyone,

thank you for your input and sorry it took me a while to reply.

For now I have created a list of issues on gitlab to be reminded.
https://invent.kde.org/teams/documentation/sprints/-/issues

Some issues I started to investigate but was struck by kapidox_generate 
being broken on my local machine. This is now addressed and will 
hopefully be fixed soon. :)


Others like the KXmlGui ones I reply to here, I will play through at 
some point and look what I can do to fill some holes.


Feel free to add issues to the issues list as you stumble over them.

Cheers,
Frederik


On 6/14/21 2:00 PM, David Hurka wrote:

Hi Frederik,

here is my report about a negative experience with existing documentation:


So what to report? Documentation that ...
- [...]
- has holes in it. For example a tutorial where you suddenly think,
you skipped an important step.
- you wish was there but you could not find it.


When I tried to understand KXmlGui an KParts (about 15 months ago?), I felt
left alone from the documentation.

KXmlGui:

KXmlGui explains itself as user configurable main windows (toolbars,
shortcuts), which should be enough for an introduction. But KXmlGui docs
didn’t give me examples how to use it. Just creating a KXmlGui main window and
putting a KXmlGuiClient in it didn’t work as easy as setting the main widget
of a QMainWindow. My experiment application always crashed at startup.

Here I would expect some minimal working examples.

It also misses an introduction about merging multiple KXmlGuiClients to one
user interface.

KParts:

KParts didn’t tell me what the whole framework is good for. After reading the
documentation, I doubted that a KPart is anything more than a KXmlGuiClient
with another name or even a QWidget with a list of actions. Why not just
instantiate a QWidget derived object from a library, and put that QWidget in
my main window?

Here I would expect an introduction why I should use KParts.

Only KReadOnlyPart and KReadWritePart made some sense for me. These were able
to provide reading and writing files through KIO just through the openUrl()
and saveAs() methods. And Konqueror can search for a KReadOnlyPart that allows
to open a specific document type, and use this part through a common API.

Cheers, David




Re: Progress is good for us but bad for documentation

2021-06-30 Thread David Hurka
On Thursday, July 1, 2021 12:03:44 AM CEST Frederik Schwarzer wrote:
> Hi everyone,
> 
> thank you for your input and sorry it took me a while to reply.
> 
> For now I have created a list of issues on gitlab to be reminded.
> https://invent.kde.org/teams/documentation/sprints/-/issues
> 
> [...]

Cool, thanks for your efforts! :)

Cheers, David