In case you guys didn't notice, the new QP/C version 5.4.0 has been released a couple of days ago.
This is an important release, because it implements two major changes in the basic approach to distributing QP and to building QP applications.
The first major change is that the QP/C download now contains all currently available ports and examples. There is no longer a need to download and install separate "QP Development Kits" (QDKs).
The second major change is that all embedded QP/C projects now include the QP/C source files, instead of linking to the QP/C library. Major concern before doing away with the library was that some unused code could be linked into the final image, thus leading to the code bloat. But experiments showed that actually the final images can be even slightly smaller when building from sources versus linking QP as library.
The trick is to use compiler options like -ffunction-sections and -fdata-sections combined with the linker options --gc-sections (for the GNU toolset), and similar options for other toolsets.
The final major change in QP/C 5.4.0 is that it is no longer necessary to define the QPC environment variable to build the examples. This is related to the new approach of building QP/C from sources in each project, and for this the QPC environment variable turns out to be much less useful. That's because most of the IDEs include sources using relative paths and it is outright impossible to force the tool to use an absolute path based on an environment variable, like QPC.
The downside of doing away with the QPC environment variable is that now you must modify the example projects (or your own projects based on the examples), if you choose to move them to a different directory relative to the QP/C source code.
But the upside is that no additional steps are needed after simply unzipping QP/C to your disk.
Any comments regarding the new release will be highly appreciated.
--MMS
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I saw this release but we are waiting the CPP release before evaluating the new version. Including the ports sounds good to me. I do like the use of relative paths. We do this as much as possible as it really helps with configuration management and automated builds.
We are now 3-4 years into using QP/QM and never set any environment variables for our builds.
If QM doesn't find things in the specific locations, it could prompt you to point to the correct location instead of just saying the model is corrupted. On occasion I have just edited the qm file directly to get around this.
This seems like incremental progress to me. Keep it up.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In case you guys didn't notice, the new QP/C version 5.4.0 has been released a couple of days ago.
This is an important release, because it implements two major changes in the basic approach to distributing QP and to building QP applications.
The first major change is that the QP/C download now contains all currently available ports and examples. There is no longer a need to download and install separate "QP Development Kits" (QDKs).
The second major change is that all embedded QP/C projects now include the QP/C source files, instead of linking to the QP/C library. Major concern before doing away with the library was that some unused code could be linked into the final image, thus leading to the code bloat. But experiments showed that actually the final images can be even slightly smaller when building from sources versus linking QP as library.
The trick is to use compiler options like -ffunction-sections and -fdata-sections combined with the linker options --gc-sections (for the GNU toolset), and similar options for other toolsets.
The final major change in QP/C 5.4.0 is that it is no longer necessary to define the
QPCenvironment variable to build the examples. This is related to the new approach of building QP/C from sources in each project, and for this theQPCenvironment variable turns out to be much less useful. That's because most of the IDEs include sources using relative paths and it is outright impossible to force the tool to use an absolute path based on an environment variable, like QPC.The downside of doing away with the
QPCenvironment variable is that now you must modify the example projects (or your own projects based on the examples), if you choose to move them to a different directory relative to the QP/C source code.But the upside is that no additional steps are needed after simply unzipping QP/C to your disk.
Any comments regarding the new release will be highly appreciated.
--MMS
I saw this release but we are waiting the CPP release before evaluating the new version. Including the ports sounds good to me. I do like the use of relative paths. We do this as much as possible as it really helps with configuration management and automated builds.
We are now 3-4 years into using QP/QM and never set any environment variables for our builds.
If QM doesn't find things in the specific locations, it could prompt you to point to the correct location instead of just saying the model is corrupted. On occasion I have just edited the qm file directly to get around this.
This seems like incremental progress to me. Keep it up.