Use build-time define to set the path to the source files
directory. Which then can be used to format path to the test
data. This allows running tests from out-of-source-tree -builds
that e.g. QtCreator does.
Test was using and assuming that severity string starts with
capital letter (e.g. "Style"). But the strings are all lowercase
letters.
Ticket #2832 (GUI: XML version 1 test fails)
Start building each test as separate project as QtestLib tests
usually are built. This commit adds the infrastructure and moves
TranslationHandler test as own project.
Fix I did yesterday gave only filename of the project file for
function loading project file. Causing the loading failing if
not in "current" directory.
If we there is project file in the directory to check then ask
user if one wants to use the project file instead. If there are
multiple project files then just tell there are project files
and ask if user wants to continue without using them.
Ticket: #2816 (GUI regression: Interrupted checking because of too many #ifdef configurations.)
If the project file does not define paths to check then check the
project root directory (which likely is the directory where the
project file is located).
Ticket #2816 (GUI regression: Interrupted checking because of too many #ifdef configurations.)
Setting organization and program name in main() allows us to
cleanup Settings class usage. As we don't need to keep using the
one instance of Settings but can create new Settings class
whenever we need to access settings. According to the Qt
documentation creating Settings class is fast.
Use project file's location as base path when adding new paths
(checked, included or ignored) to the project. In most cases user
wants to add paths in the same project so this reduces browsing
paths considerably when adding them.
When project files support was added to the GUI there was no GUI
for them and automatic/silent loading was added. So that if the
directory contained project file with the same name (and .cppcheck
extension) then the project file was automatically loaded and used
for the checking.
This can be very confusing for the user as there is no any
indication that the project file is used. But this solution was
necessary at that time to get project file support added.
Now that we have usable GUI for the project files this automatic/
silent loading can be removed. Nobody really should be using it
anymore. And even if the automatic loading is needed one can give
the project file for the GUI using command line parameter.
The project file to check just GUI code was missing the directory
to check. This is probably due it was used originally as
"automatically" loaded project file which assumed current
directory is checked and only added some additional parameters.
If the project file in MRU list does not exist ask user if one
wants to remove the file from the list. If user agrees then the
file is removed from the list. Otherwise the file is left to the
list but not tried to open. User may have accidentally moved or
renamed the file so we give a possibility to add it back and not
just blindly removing it from the list.
Add MRU items for project files to File-menu. When user creates
a new project file or opens existing project file it is added to
the list of recently used projects. Last 5 projects are remembered
and available for quick acess in the File-menu.
The ErrorLogger::reportStatus() is not lib code interface. The CLI
code does the looping through file list and gives one file at a
time for the core code. Hence lib has no any idea about the
progress and it can't provide such information.
Also the recent commit (6d858b6) caused a GUI build failure by
adding CLI code dependency to GUI. Which is big no-no.
This is admittedly a hack. But it allow us to build all modules
again.
Two Qt modules are not needed any more in the CMake script for the graphical
user interface after the commit "GUI: Open online-help instead of local help".
3965a08b7b (commit)
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Unify usage and API of CppCheck class. Allow only one file checked
at a time, instead of list of files. Clients can then handle file
lists more naturally and as they see fit. Also clients have better
knowledge of how checking status should be handled.
The single-threaded CLI checking was only one using the file list.
Other clients were giving files (to list) one file at a time.
Add new "Advanced" page to preferences-dialog and add there a
checkbox for enabling inconclusive checks. Now that checkbox is
the only control in that new page but there will be more controls
later on.
This is the first (and quick) support for the inconclusive errors.
We simply add [Inconclusive] to begin of the summary. This is
temporary solution until better GUI is implemented. XML v1 won't
be supporting inconclusive errors. For XML v2 we need still to
decide what to do.
GUI now recognizes -p <project file> command line parameter. When
given (with path to valid project file) GUI automatically loads
the project file and starts checking paths in it.
Ticket: #2613 (GUI: Should accept project file from command line)
