On 09/25/2017 10:15 AM, Mateusz Loskot wrote:
> What if (Windows) user runs cmake inside
>
> c:\my awesome projects\one-superb\build
>
> and there is xxx_command(${CMAKE_SOURCE_DIR})
Indeed.
In my opinion, if software cannot handle arbitrary path names which
contain anything then that software
On 25 September 2017 at 16:58, Miller Henry wrote:
> To add fuel to this, I like to argue that paths should not be quoted if at
> all possible.
I agree.
> I find that in many cases where a path is quoted those quotes are being done
> to
> work around a bad project structure and you can reorgan
To add fuel to this, I like to argue that paths should not be quoted if at all
possible. I find that in many cases where a path is quoted those quotes are
being done to work around a bad project structure and you can reorganize your
project to get rid of the need for quotes.
-Original Mess
On 25 September 2017 at 12:57, Oleksii Vilchanskyi
wrote:
> As usually with CMake, there are no recommendations/guidelines.
So, cases with the ammo for CMake sceptics and opponents are not
empty, yet. Pity.
> However, here's my logic:
>
> 1) if it's a path, always quote it
> 2) if it's not a pat
As usually with CMake, there are no recommendations/guidelines.
However, here's my logic:
1) if it's a path, always quote it
2) if it's not a pat, but inside an if() or any similar core language
structure, quote it as well
3) don't quote only if you're sure the string can't have spaces - otherwi
Hi,
A user of one of projects I maintain pointed out that according to
CMake guidelines [1] all variables with strings (also paths) should be
quoted, ie.
include_directories(${SOCI_SOURCE_DIR}/core)
should read
include_directories("${SOCI_SOURCE_DIR}/core")
Is that so?
What is the current CMak
