support for -fsyntax-only (and generating Qt/KDE's auto-generated content)

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

support for -fsyntax-only (and generating Qt/KDE's auto-generated content)

René J. V.  Bertin
Hi,

Apologies, longish post ahead. I've tried to present my idea and the thought train leading up to it as succinctly as possible. Hope I at least strike a chord!

Clang and GCC have long supported an option that makes them stop after the syntax-verification stage: -fsyntax-only . This has the advantage (see below) that it's much faster than a regular build and that no output is generated. The absent output is also a problem and the reason I'm posting about it here:
- compiler checking fails because of the missing output.
- link and archive (static lib) creation fail because of missing files.

The first problem should not be hard to fix (filter out -fsyntax-only from the arguments used to check the compiler). The 2nd problem can be addressed by ignoring the exit code from linking and archiving commands (possible with make, presumably with ninja too).

Would it be feasible to implement "something" that makes it possible to run a full pure-syntax-checking "build", either as a special target or as a separate mode of operation or CMAKE_BUILD_TYPE?

I think this could be useful in general esp. with larger projects, allowing to check "quickly" if a change (triggering a full rebuild) breaks something. QtWebKit would be an appropriate example: it uses a central header to set the configuration preprocessor tokens so toggling even one of these switches causes *everything* to be rebuilt.

Some more observations which outline a context where cmake-level support for a pure syntax-checking run would be beneficial (also the context that made me remember the -fsyntax-only option):

- a number of IDEs (can) use CMake as the basis for project definition.
- They also provide parsing facilities that also use information from cmake to control the parser.
- KDE has long used cmake instead of autoconf (or qmake) and is based on Qt, which means KDE projects depend on auto-generation of files which need to be included in C++ code.
- Parsing or even syntax-checking won't work to at least some degree without those auto-generated files.
- opening a project in an IDE is not always done with the intention to build it; in absence of such an intention one usually does expect to be able to rely on parsing and syntax checking.
- Auto-generation of Qt's automatic content occurs during a full build, when needed.

That last observation is the big bottleneck; a full build can be very costly. If there were a dedicated target to generate just all automatic content one could just build that target and there would be no issue left. Whether or not this is impossible is unclear, and at least not entirely a CMake issue.

Here too something like -DCMAKE_BUILD_TYPE=SyntaxOnly would be a workable solution.

R.

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: support for -fsyntax-only (and generating Qt/KDE's auto-generated content)

Sylvain Joubert
I'd also like something like that for another use case of mine which
stumble upon the same limitations (compiler checks, linking and Qt
generated content).

My use case is for static analysis builds. For example, my CI setup has
multiple of them including cppcheck, clang-tidy and iwyu through the
CMake integration. And since I'd like to keep separate builds for each
of them this requires 3 full build whose results I don't really care.

So if we can achieve a light build mode, that would be great. In my case
I could completely deactivate the build part including the syntax
checking since that's done by the static analysis tools anyway. Thinking
of that maybe we can completely disable the build invocation and add
support for a "syntax only" analysis tool that would feats your need.

Anyhow, we can't deactivate all the build. As you said auto-generated
content, custom targets,... would need to stay.

Sylvain

Le 09/10/2018 à 16:38, René J.V. Bertin a écrit :

> Hi,
>
> Apologies, longish post ahead. I've tried to present my idea and the thought train leading up to it as succinctly as possible. Hope I at least strike a chord!
>
> Clang and GCC have long supported an option that makes them stop after the syntax-verification stage: -fsyntax-only . This has the advantage (see below) that it's much faster than a regular build and that no output is generated. The absent output is also a problem and the reason I'm posting about it here:
> - compiler checking fails because of the missing output.
> - link and archive (static lib) creation fail because of missing files.
>
> The first problem should not be hard to fix (filter out -fsyntax-only from the arguments used to check the compiler). The 2nd problem can be addressed by ignoring the exit code from linking and archiving commands (possible with make, presumably with ninja too).
>
> Would it be feasible to implement "something" that makes it possible to run a full pure-syntax-checking "build", either as a special target or as a separate mode of operation or CMAKE_BUILD_TYPE?
>
> I think this could be useful in general esp. with larger projects, allowing to check "quickly" if a change (triggering a full rebuild) breaks something. QtWebKit would be an appropriate example: it uses a central header to set the configuration preprocessor tokens so toggling even one of these switches causes *everything* to be rebuilt.
>
> Some more observations which outline a context where cmake-level support for a pure syntax-checking run would be beneficial (also the context that made me remember the -fsyntax-only option):
>
> - a number of IDEs (can) use CMake as the basis for project definition.
> - They also provide parsing facilities that also use information from cmake to control the parser.
> - KDE has long used cmake instead of autoconf (or qmake) and is based on Qt, which means KDE projects depend on auto-generation of files which need to be included in C++ code.
> - Parsing or even syntax-checking won't work to at least some degree without those auto-generated files.
> - opening a project in an IDE is not always done with the intention to build it; in absence of such an intention one usually does expect to be able to rely on parsing and syntax checking.
> - Auto-generation of Qt's automatic content occurs during a full build, when needed.
>
> That last observation is the big bottleneck; a full build can be very costly. If there were a dedicated target to generate just all automatic content one could just build that target and there would be no issue left. Whether or not this is impossible is unclear, and at least not entirely a CMake issue.
>
> Here too something like -DCMAKE_BUILD_TYPE=SyntaxOnly would be a workable solution.
>
> R.
>

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: support for -fsyntax-only (and generating Qt/KDE's auto-generated content)

René J. V.  Bertin
Sylvain Joubert wrote:

> My use case is for static analysis builds. For example, my CI setup has
> multiple of them including cppcheck, clang-tidy and iwyu through the
> CMake integration. And since I'd like to keep separate builds for each
> of them this requires 3 full build whose results I don't really care.

Are you thinking of tools that are invoked instead of the compiler, like clazy-
standalone? I thought about mentioning a potential interest of my idea for using
such tools (but forgot in the end).

Specific support for -fsyntax-only may not be relevant for those tools, but a
build mode where the final step of each build product is not taken would probably
be useful there, indeed. Such a mode might even create an empty file with the
intended name, so that there's something to refer to later during a build.

I've been considering to write a little wrapper one could "inject" using
CMAKE_<LANG>_COMPILER_LAUNCHER but there is no equivalent for the final product
generation step (linker, librarian).

>
> So if we can achieve a light build mode, that would be great. In my case
> I could completely deactivate the build part including the syntax
> checking since that's done by the static analysis tools anyway.

You'd get that by setting your analysis tool as the compiler.

> Anyhow, we can't deactivate all the build. As you said auto-generated
> content, custom targets,... would need to stay.

And besides, cmake's goal is to create files with which one can build projects.
Generating something that doesn't attempt to build at all could well require a
lot more implementation effort than pretending the linker/librarian step always
succeeds.

FWIW, I notice that the link step now takes the form

cmake -E cmake_link_script CMakeFiles/<target>.dir/link.txt

IOW there are 2 levels where linker errors due to missing objects can be
intercepted: in the link.txt script, and in cmake itself.

R.

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: support for -fsyntax-only (and generating Qt/KDE's auto-generated content)

Sylvain Joubert
> Are you thinking of tools that are invoked instead of the compiler, like clazy-
> standalone? I thought about mentioning a potential interest of my idea for using
> such tools (but forgot in the end).

Yes, that and all the other tools supported by CMake as a "pre-command"
before the compiler invocation (e.g. clang-tidy, iwyu,...)

> Specific support for -fsyntax-only may not be relevant for those tools, but a
> build mode where the final step of each build product is not taken would probably
> be useful there, indeed. Such a mode might even create an empty file with the
> intended name, so that there's something to refer to later during a build.
>
> I've been considering to write a little wrapper one could "inject" using
> CMAKE_<LANG>_COMPILER_LAUNCHER but there is no equivalent for the final product
> generation step (linker, librarian).
>
>>
>> So if we can achieve a light build mode, that would be great. In my case
>> I could completely deactivate the build part including the syntax
>> checking since that's done by the static analysis tools anyway.
>
> You'd get that by setting your analysis tool as the compiler.

I did not think of doing that. I'll have to play with it, but I think
the final product step will still be an issue.

Sylvain
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake