From ben.boeckel at kitware.com Wed Jan 2 13:20:56 2019 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 2 Jan 2019 13:20:56 -0500 Subject: [cmake-developers] Referencing all sources in compile command In-Reply-To: References: <20181231221721.GA850@rotor.localdomain> Message-ID: <20190102182056.GA27627@rotor.localdomain> On Mon, Dec 31, 2018 at 15:30:28 -0800, Saleem Abdulrasool wrote: > AFAIK, the driver interface is supposed to be stable. The frontend options > are not, but, the same holds true for clang as well. The driver options > are stable, and we (as the clang developer community) aim to not break > that. However, the frontend flags are entirely in the purview of the > compiler developers and those change as needed. OK, that's good to hear. > swiftc -c -primary-file -o -emit-module-path > .swiftmodule -emit-module-doc-path .swiftdoc > > > This allows the compiler to look through the other sources which will be > part of the module and perform semantic analysis across them if/when > necessary. > > Adding per file properties would still be possible, and, IMO, desired. > That is part of the reason for doing the compilation in this mode rather > than a single pass over the complete file set. That said, most of the > options really should be at a module level. Ah, I see. This is also news to me. I think adding `` would be suitable. However, it might need to be `` since I suspect `swiftc` won't take kindly to C++, C, or their headers files sneaking in on its commandline. > On Mon, Dec 31, 2018 at 2:17 PM Ben Boeckel wrote: > > Other questions which spring to mind: > > > > - Does it support making just the compile artifacts from the source > > files or does it always do the link step? > > The approach that I am taking does a separate compile and link step. This > allows for a better behavior when it comes to incremental builds which I > care about. > > > - If the latter, how do mixed language libraries work? > > The latter is what I believe most people have done, partially due to lack > of understanding of how the build model works with swift which is > completely understandable given that it is relatively opaque and it has not > been documented as thoroughly as C/C++. > > > - Also, if linking is done by Swift, how would one add a manifest or > > .rc file on Windows (e.g., to get an application icon)? > > Well, you would still want to link using the swift driver, not the linker > directly much like you use the driver to link C/C++. I believe the changes > have also been back ported to the 5.0 release to pass options from the > [swift] driver to the [clang] driver to have them be translated > appropriately for the linker in use. But, the manifest and resource file > handling is done by the linker IIRC, so this is largely unchanged beyond > the need to pass along the right flags. It sounds like `swiftc` is now much closer to the C++ separate TU compilation model that CMake kind of assumes now (or at least supports it). This should be fine then. > > The list of restrictions would need to be well-defined here first I > > think. > > I think that there aren't very many restrictions that come to mind. The > biggest one is that it would be *extremely* helpful to have language > specific properties that can be set, but, I really was hoping that there > was a way to do this with a backwards compatible manner. It would be > helpful to have a property to indicate things like the swift version and > the module name. Language-specific properties are fine for a new language. The only backwards compat I can think of is if people were using the now-important property names before, but I think that since doing `enable_language(Swift)` is an explicit action, developers can ensure that their conflicting property names are not an issue. > I'm happy to go into more detail, but, I'm really not sure I have an > understanding of what things you may be thinking of as restrictions here. I haven't thought too deeply on it either, but experience has shown that there are always corner cases. As long as the initial implementation is explicit about its use cases and errors on anything not tested, relaxing it for future use cases is easier than allowing everything and using policies to fix what is broken. Thanks, --Ben From compnerd at compnerd.org Wed Jan 2 13:30:38 2019 From: compnerd at compnerd.org (Saleem Abdulrasool) Date: Wed, 2 Jan 2019 10:30:38 -0800 Subject: [cmake-developers] Referencing all sources in compile command In-Reply-To: <20190102182056.GA27627@rotor.localdomain> References: <20181231221721.GA850@rotor.localdomain> <20190102182056.GA27627@rotor.localdomain> Message-ID: On Wed, Jan 2, 2019 at 10:20 AM Ben Boeckel wrote: > On Mon, Dec 31, 2018 at 15:30:28 -0800, Saleem Abdulrasool wrote: > > AFAIK, the driver interface is supposed to be stable. The frontend > options > > are not, but, the same holds true for clang as well. The driver options > > are stable, and we (as the clang developer community) aim to not break > > that. However, the frontend flags are entirely in the purview of the > > compiler developers and those change as needed. > > OK, that's good to hear. > > > swiftc -c -primary-file -o -emit-module-path > > .swiftmodule -emit-module-doc-path .swiftdoc > > > > > > This allows the compiler to look through the other sources which will be > > part of the module and perform semantic analysis across them if/when > > necessary. > > > > Adding per file properties would still be possible, and, IMO, desired. > > That is part of the reason for doing the compilation in this mode rather > > than a single pass over the complete file set. That said, most of the > > options really should be at a module level. > > Ah, I see. This is also news to me. I think adding `` > would be suitable. However, it might need to be `` > since I suspect `swiftc` won't take kindly to C++, C, or their headers > files sneaking in on its commandline. > Interesting idea. I was thinking that for the initial implementation, we could make this harder to use instead. Swift libraries should only be given swift sources. You build your C sources (if any, this should/is fairly rare) as a separate object library and link it into the final link. However, if filtering the sources is there, that would certainly be a nice feature. I don't see any placeholders with this behaviour currently. Any suggestions on how to best handle this? > > On Mon, Dec 31, 2018 at 2:17 PM Ben Boeckel > wrote: > > > Other questions which spring to mind: > > > > > > - Does it support making just the compile artifacts from the source > > > files or does it always do the link step? > > > > The approach that I am taking does a separate compile and link step. > This > > allows for a better behavior when it comes to incremental builds which I > > care about. > > > > > - If the latter, how do mixed language libraries work? > > > > The latter is what I believe most people have done, partially due to lack > > of understanding of how the build model works with swift which is > > completely understandable given that it is relatively opaque and it has > not > > been documented as thoroughly as C/C++. > > > > > - Also, if linking is done by Swift, how would one add a manifest or > > > .rc file on Windows (e.g., to get an application icon)? > > > > Well, you would still want to link using the swift driver, not the linker > > directly much like you use the driver to link C/C++. I believe the > changes > > have also been back ported to the 5.0 release to pass options from the > > [swift] driver to the [clang] driver to have them be translated > > appropriately for the linker in use. But, the manifest and resource file > > handling is done by the linker IIRC, so this is largely unchanged beyond > > the need to pass along the right flags. > > It sounds like `swiftc` is now much closer to the C++ separate TU > compilation model that CMake kind of assumes now (or at least supports > it). This should be fine then. > > > > The list of restrictions would need to be well-defined here first I > > > think. > > > > I think that there aren't very many restrictions that come to mind. The > > biggest one is that it would be *extremely* helpful to have language > > specific properties that can be set, but, I really was hoping that there > > was a way to do this with a backwards compatible manner. It would be > > helpful to have a property to indicate things like the swift version and > > the module name. > > Language-specific properties are fine for a new language. The only > backwards compat I can think of is if people were using the > now-important property names before, but I think that since doing > `enable_language(Swift)` is an explicit action, developers can ensure > that their conflicting property names are not an issue. > > > I'm happy to go into more detail, but, I'm really not sure I have an > > understanding of what things you may be thinking of as restrictions here. > > I haven't thought too deeply on it either, but experience has shown that > there are always corner cases. As long as the initial implementation is > explicit about its use cases and errors on anything not tested, relaxing > it for future use cases is easier than allowing everything and using > policies to fix what is broken. > Yeah, the corner cases always come out. I think that having something that works is usually a good starting point to getting to the point where the corner cases can be considered. I think that we are in agreement that being stringent and relaxing is easier than being accepting and then tightening the requirements later. > Thanks, > > --Ben > -- Saleem Abdulrasool compnerd (at) compnerd (dot) org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinofifa at gmail.com Sun Jan 6 10:20:39 2019 From: dinofifa at gmail.com (dinofifa) Date: Sun, 6 Jan 2019 10:20:39 -0500 Subject: [cmake-developers] help: any tools to create user id & password Message-ID: Good morning, I try to commercialize a Windows based application build with Cmake. Is there any tools to achieve the following goals? 1. encrypt the whole build or certain sensitive files 2. generate user id and password for each customers 3. set expiration date for each user access Jackie -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Tue Jan 8 06:44:47 2019 From: brad.king at kitware.com (Brad King) Date: Tue, 8 Jan 2019 06:44:47 -0500 Subject: [cmake-developers] BISON_TARGET doesn't use CMAKE_CURRENT_BINARY_DIR as WORKING_DIRECTORY In-Reply-To: References: Message-ID: <287722ae-397c-ab30-cfc8-82876f0f61d4@kitware.com> On 12/25/18 1:17 AM, Mingjie Xing wrote: > The BISON_TARGET will run bison command in CMAKE_CURRENT_SOURCE_DIR. > > So I just wonder whither it is better for BISON_TARGET to use > CMAKE_CURRENT_BINARY_DIR as WORKING_DIRECTORY. Unfortunately this went unnoticed for years after the module was added. Changing it now would require a policy. -Brad From brad.king at kitware.com Tue Jan 8 10:59:04 2019 From: brad.king at kitware.com (Brad King) Date: Tue, 8 Jan 2019 10:59:04 -0500 Subject: [cmake-developers] BISON_TARGET doesn't use CMAKE_CURRENT_BINARY_DIR as WORKING_DIRECTORY In-Reply-To: <287722ae-397c-ab30-cfc8-82876f0f61d4@kitware.com> References: <287722ae-397c-ab30-cfc8-82876f0f61d4@kitware.com> Message-ID: <96240f88-30e3-ac02-1b96-222703b4e9ef@kitware.com> On 1/8/19 6:44 AM, Brad King wrote: > On 12/25/18 1:17 AM, Mingjie Xing wrote: >> The BISON_TARGET will run bison command in CMAKE_CURRENT_SOURCE_DIR. >> >> So I just wonder whither it is better for BISON_TARGET to use >> CMAKE_CURRENT_BINARY_DIR as WORKING_DIRECTORY. > > Unfortunately this went unnoticed for years after the module was > added. Changing it now would require a policy. See proposed policy here: https://gitlab.kitware.com/cmake/cmake/merge_requests/2774 -Brad From Torsten at Robitzki.de Mon Jan 14 04:21:37 2019 From: Torsten at Robitzki.de (Torsten Robitzki) Date: Mon, 14 Jan 2019 10:21:37 +0100 Subject: [cmake-developers] Support for list length expression in if()-command? Message-ID: <8B5B4D18-221C-46A5-83B9-7A8C80821D44@Robitzki.de> Hi, I have a customer that requires quite often to check, whether a list contains at least a given number of elements. As we do not have functions with return values, this requires him to inquire the length of a list before taking special actions. To simplify that task (and without larger changes in CMake [like introducing *real* functions]), he came up with the idea to extend the if()-command with a LENGTH operator: set(list) ? if (LENGTH list GREATER 1) ? endif() Would such an extension be accepted as pull request, if we would provide it? regards, Torsten -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From brad.king at kitware.com Mon Jan 14 06:44:03 2019 From: brad.king at kitware.com (Brad King) Date: Mon, 14 Jan 2019 06:44:03 -0500 Subject: [cmake-developers] Support for list length expression in if()-command? In-Reply-To: <8B5B4D18-221C-46A5-83B9-7A8C80821D44@Robitzki.de> References: <8B5B4D18-221C-46A5-83B9-7A8C80821D44@Robitzki.de> Message-ID: <1eebb310-2cb7-ba90-08de-ccb4c971a547@kitware.com> On 1/14/19 4:21 AM, Torsten Robitzki wrote: > if (LENGTH list GREATER 1) An investigation will be needed to determine whether a policy is needed to add this to the if() command to avoid possible behavior changes for existing callers. For reference, you asked this previously: https://cmake.org/pipermail/cmake-developers/2018-December/030941.html I've almost never needed to test the length of a list in CMake code. It's not very common in my experience. What is your customer trying to do? -Brad From robert.maynard at kitware.com Mon Jan 14 15:56:41 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 14 Jan 2019 14:56:41 -0600 Subject: [cmake-developers] [ANNOUNCE] CMake 3.13.3 available for download Message-ID: We are pleased to announce that CMake 3.13.3 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! * The VS 2017 generator has been fixed to work when VS 2019 is installed. ------------------------------------------------------------------------- Changes in 3.13.3 since 3.13.2: Brad King (4): VS: Exclude VS 2019 instances when using VS 2017 generator Tests: Add cases for -{C,D,U} without a source tree Tests: Add case for warning when AUTOMOC/UIC/RCC gets disabled CMake 3.13.3 Craig Scott (2): cmake: Stop processing if -P option lacks file name cmake: Ensure source and binary dirs are set Paul Seyfert (1): cmake: distinguish '-Cpath' from '-C path' in source dir parsing Sebastian Holtermann (1): Autogen: Issue a warning when AUTOMOC/UIC/RCC gets disabled. Tim Blechmann (1): BundleUtilities: Ensure target dir exists when creating symlinks From venytch at gmail.com Wed Jan 16 15:27:13 2019 From: venytch at gmail.com (Venedict Tchistopolskii) Date: Wed, 16 Jan 2019 12:27:13 -0800 Subject: [cmake-developers] CMake GUI "Stop" button does not halt exec_process Message-ID: Pressing "STOP" in the CMake GUI interface halts CMake itself but does not stop any execute_process that is going on at the time. This makes it hang until the process finishes, since no interrupt is sent...... Aggravating when you're using an exterior script (e.g. a .exe or .py) that e.g. handles package maintenance. Would hang up for the entire duration of ~40 minutes unless you force kill that sub process. I think force-killing CMake GUI also won't forward the kill to the exec_process, orphaning it.....>.< My reproduction: Windows 10 CMake script via CMakeLists.txt files Executing a Python script PyInstalled into a .exe for windows use -> Downloads and untars some SDK's and shows progress (plus a bit more) but takes 40-70 minutes average. Canceling CMake won't cancel python script -> 70min hangup or requirement to use task manage and force-kill subprocess. Let me know any suggestions or possible fixes -------------- next part -------------- An HTML attachment was scrubbed... URL: From frodak17 at gmail.com Wed Jan 16 15:52:36 2019 From: frodak17 at gmail.com (frodak17) Date: Wed, 16 Jan 2019 15:52:36 -0500 Subject: [cmake-developers] CMake GUI "Stop" button does not halt exec_process In-Reply-To: References: Message-ID: On Wed, Jan 16, 2019 at 3:27 PM Venedict Tchistopolskii wrote: > Pressing "STOP" in the CMake GUI interface halts CMake itself but does not > stop any execute_process that is going on at the time. This makes it hang > until the process finishes, since no interrupt is sent...... > > Aggravating when you're using an exterior script (e.g. a .exe or .py) that > e.g. handles package maintenance. Would hang up for the entire duration of > ~40 minutes unless you force kill that sub process. > > I think force-killing CMake GUI also won't forward the kill to the > exec_process, orphaning it.....>.< > > My reproduction: > Windows 10 > CMake script via CMakeLists.txt files > Executing a Python script PyInstalled into a .exe for windows use -> > Downloads and untars some SDK's and shows progress (plus a bit more) but > takes 40-70 minutes average. > > Canceling CMake won't cancel python script -> 70min hangup or requirement > to use task manage and force-kill subprocess. > > Let me know any suggestions or possible fixes > -- > > I commented on this about a month ago: > Looks like this would require a code change how the GUI works and the > internal way execute_process works. Now execute_process knows how to > cancel a process due to time out, but it didn't seem to check for anything > else. Essentially it looks like execute_process needs to be signaled by > the button press to cancel the process in addition to checking for > timeout. There are other internal interrupt flags that seem to be set when > the GUI stop button is pressed. Anyways this is what I noticed in the > code base. > So in the execute_process function it sits in a loop waiting for the process to finish. If the timeout occurs it kills the process. At the same time when the GUI stop button is pressed it sets some sort of abort flag that is used during command processing to quit processing commands. It seems that someone should be able to take this abort flag and use it to not only stop the command processing loop but to also have the execute_process timeout loop to kill the process if the abort flag is set. Best regards, F -------------- next part -------------- An HTML attachment was scrubbed... URL: From venytch at gmail.com Wed Jan 16 16:09:32 2019 From: venytch at gmail.com (Venedict Tchistopolskii) Date: Wed, 16 Jan 2019 13:09:32 -0800 Subject: [cmake-developers] CMake GUI "Stop" button does not halt exec_process In-Reply-To: References: Message-ID: That'd be great if it could be implemented. Is there any way to incorporate that functionality into a custom CMake build? I don't know the process to generate a custom CMake GUI exe, any resources available on that>? On Wed, Jan 16, 2019 at 12:52 PM frodak17 wrote: > > > On Wed, Jan 16, 2019 at 3:27 PM Venedict Tchistopolskii > wrote: > >> Pressing "STOP" in the CMake GUI interface halts CMake itself but does >> not stop any execute_process that is going on at the time. This makes it >> hang until the process finishes, since no interrupt is sent...... >> >> Aggravating when you're using an exterior script (e.g. a .exe or .py) >> that e.g. handles package maintenance. Would hang up for the entire >> duration of ~40 minutes unless you force kill that sub process. >> >> I think force-killing CMake GUI also won't forward the kill to the >> exec_process, orphaning it.....>.< >> >> My reproduction: >> Windows 10 >> CMake script via CMakeLists.txt files >> Executing a Python script PyInstalled into a .exe for windows use -> >> Downloads and untars some SDK's and shows progress (plus a bit more) but >> takes 40-70 minutes average. >> >> Canceling CMake won't cancel python script -> 70min hangup or requirement >> to use task manage and force-kill subprocess. >> >> Let me know any suggestions or possible fixes >> -- >> >> > I commented on this about a month ago: > >> Looks like this would require a code change how the GUI works and the >> internal way execute_process works. Now execute_process knows how to >> cancel a process due to time out, but it didn't seem to check for anything >> else. Essentially it looks like execute_process needs to be signaled by >> the button press to cancel the process in addition to checking for >> timeout. There are other internal interrupt flags that seem to be set when >> the GUI stop button is pressed. Anyways this is what I noticed in the >> code base. >> > > So in the execute_process function it sits in a loop waiting for the > process to finish. If the timeout occurs it kills the process. > At the same time when the GUI stop button is pressed it sets some sort of > abort flag that is used during command processing to quit processing > commands. > It seems that someone should be able to take this abort flag and use it to > not only stop the command processing loop but to also have the > execute_process timeout loop to kill the process if the abort flag is set. > > Best regards, > F > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Torsten at Robitzki.de Tue Jan 22 03:08:36 2019 From: Torsten at Robitzki.de (Torsten at Robitzki.de) Date: Tue, 22 Jan 2019 09:08:36 +0100 Subject: [cmake-developers] Support for list length expression in if()-command? In-Reply-To: <1eebb310-2cb7-ba90-08de-ccb4c971a547@kitware.com> References: <8B5B4D18-221C-46A5-83B9-7A8C80821D44@Robitzki.de> <1eebb310-2cb7-ba90-08de-ccb4c971a547@kitware.com> Message-ID: <5B569339-39AA-4CE3-AC7A-57D853347CEF@Robitzki.de> Hi Brad, > Am 14.01.2019 um 12:44 schrieb Brad King : > > I've almost never needed to test the length of a list in CMake > code. It's not very common in my experience. What is your > customer trying to do? Sorry for the late response! I?ve asked him. Mainly, he has three use cases: - Checking for empty lists (I?ve showed him that this can be done by a string compare). - Checking for lists having more than 1 entry - Checking for equal size of two lists. For example, if you want to pass pairs or tuples to a function. (example: f(firsts seconds)) regards, Torsten -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From brad.king at kitware.com Tue Jan 22 06:42:40 2019 From: brad.king at kitware.com (Brad King) Date: Tue, 22 Jan 2019 06:42:40 -0500 Subject: [cmake-developers] Support for list length expression in if()-command? In-Reply-To: <5B569339-39AA-4CE3-AC7A-57D853347CEF@Robitzki.de> References: <8B5B4D18-221C-46A5-83B9-7A8C80821D44@Robitzki.de> <1eebb310-2cb7-ba90-08de-ccb4c971a547@kitware.com> <5B569339-39AA-4CE3-AC7A-57D853347CEF@Robitzki.de> Message-ID: <377b97ce-6f62-a28a-4117-0d09391d0b77@kitware.com> On 1/22/19 3:08 AM, Torsten at Robitzki.de wrote: > three use cases: > > - Checking for empty lists (I?ve showed him that this can be done > by a string compare). > - Checking for lists having more than 1 entry > - Checking for equal size of two lists. For example, if you want > to pass pairs or tuples to a function. (example: f(firsts seconds)) Rather than a special `if` syntax, perhaps we could introduce an explicit `$LIST_LENGTH{mylist}` syntax. One would need to experiment to see if modifying the variable expansion parser (under CMP0053 NEW behavior only) to support this would have a significant performance impact. -Brad From Torsten at Robitzki.de Tue Jan 22 07:09:00 2019 From: Torsten at Robitzki.de (Torsten at Robitzki.de) Date: Tue, 22 Jan 2019 13:09:00 +0100 Subject: [cmake-developers] Support for list length expression in if()-command? In-Reply-To: <377b97ce-6f62-a28a-4117-0d09391d0b77@kitware.com> References: <8B5B4D18-221C-46A5-83B9-7A8C80821D44@Robitzki.de> <1eebb310-2cb7-ba90-08de-ccb4c971a547@kitware.com> <5B569339-39AA-4CE3-AC7A-57D853347CEF@Robitzki.de> <377b97ce-6f62-a28a-4117-0d09391d0b77@kitware.com> Message-ID: <91A2CDCB-EC38-4493-BDE0-C9D2E9228899@Robitzki.de> > Am 22.01.2019 um 12:42 schrieb Brad King : > > > Rather than a special `if` syntax, perhaps we could introduce an > explicit `$LIST_LENGTH{mylist}` syntax. One would need to experiment > to see if modifying the variable expansion parser (under CMP0053 NEW > behavior only) to support this would have a significant performance > impact. What would be a good experiment setup? Timing the CMake configuration process itself (I mean the time it takes the configuration step, when building CMake with CMake). How about adding the ability to add such function? Like: procedure(LIST_LENGTH list) list(LENGTH list length) return(${length}) endprocedure() -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From brad.king at kitware.com Tue Jan 22 07:33:42 2019 From: brad.king at kitware.com (Brad King) Date: Tue, 22 Jan 2019 07:33:42 -0500 Subject: [cmake-developers] $LIST_LENGTH{} syntax (was: Support for list length expression in if()-command?) In-Reply-To: <91A2CDCB-EC38-4493-BDE0-C9D2E9228899@Robitzki.de> References: <8B5B4D18-221C-46A5-83B9-7A8C80821D44@Robitzki.de> <1eebb310-2cb7-ba90-08de-ccb4c971a547@kitware.com> <5B569339-39AA-4CE3-AC7A-57D853347CEF@Robitzki.de> <377b97ce-6f62-a28a-4117-0d09391d0b77@kitware.com> <91A2CDCB-EC38-4493-BDE0-C9D2E9228899@Robitzki.de> Message-ID: <7dd53928-49f5-d61c-3ff0-e23b503824cb@kitware.com> On 1/22/19 7:09 AM, Torsten at Robitzki.de wrote: >> Am 22.01.2019 um 12:42 schrieb Brad King: >> Rather than a special `if` syntax, perhaps we could introduce an >> explicit `$LIST_LENGTH{mylist}` syntax. One would need to experiment >> to see if modifying the variable expansion parser (under CMP0053 NEW >> behavior only) to support this would have a significant performance >> impact. > > What would be a good experiment setup? Using `cmake -P test.cmake` to run a script that does a lot of variable evaluations without the proposed syntax, and later with it. > How about adding the ability to add such function? Like: > > procedure(LIST_LENGTH list) > list(LENGTH list length) > return(${length}) > endprocedure() We don't have a syntax for invoking functions with return values. That's a whole other discussion. -Brad From brad.king at kitware.com Tue Jan 22 07:45:56 2019 From: brad.king at kitware.com (Brad King) Date: Tue, 22 Jan 2019 07:45:56 -0500 Subject: [cmake-developers] $LIST_LENGTH{} syntax (was: Support for list length expression in if()-command?) In-Reply-To: <36327d7c10fdd6d783878d75482c4b9b@webmail-alfa3018.alfahosting-server.de> References: <8B5B4D18-221C-46A5-83B9-7A8C80821D44@Robitzki.de> <1eebb310-2cb7-ba90-08de-ccb4c971a547@kitware.com> <5B569339-39AA-4CE3-AC7A-57D853347CEF@Robitzki.de> <377b97ce-6f62-a28a-4117-0d09391d0b77@kitware.com> <91A2CDCB-EC38-4493-BDE0-C9D2E9228899@Robitzki.de> <7dd53928-49f5-d61c-3ff0-e23b503824cb@kitware.com> <36327d7c10fdd6d783878d75482c4b9b@webmail-alfa3018.alfahosting-server.de> Message-ID: On 1/22/19 7:40 AM, Daniel Franke wrote: > Whats about a Syntax like > > ${list::LENGTH} That would require dispatch after matching `${VAR}` syntax, and that lookup is one of the hottest paths according to profiling. We already have $ENV{} and $CACHE{} syntax. -Brad From Torsten at Robitzki.de Tue Jan 22 10:28:55 2019 From: Torsten at Robitzki.de (Torsten at Robitzki.de) Date: Tue, 22 Jan 2019 16:28:55 +0100 Subject: [cmake-developers] real functions (was: $LIST_LENGTH{} syntax) In-Reply-To: <7dd53928-49f5-d61c-3ff0-e23b503824cb@kitware.com> References: <8B5B4D18-221C-46A5-83B9-7A8C80821D44@Robitzki.de> <1eebb310-2cb7-ba90-08de-ccb4c971a547@kitware.com> <5B569339-39AA-4CE3-AC7A-57D853347CEF@Robitzki.de> <377b97ce-6f62-a28a-4117-0d09391d0b77@kitware.com> <91A2CDCB-EC38-4493-BDE0-C9D2E9228899@Robitzki.de> <7dd53928-49f5-d61c-3ff0-e23b503824cb@kitware.com> Message-ID: > Am 22.01.2019 um 13:33 schrieb Brad King : > > On 1/22/19 7:09 AM, Torsten at Robitzki.de wrote: > >> How about adding the ability to add such function? Like: >> >> procedure(LIST_LENGTH list) >> list(LENGTH list length) >> return(${length}) >> endprocedure() > > We don't have a syntax for invoking functions with return values. > That?s a whole other discussion. With `$CACHE{VAR}` and `$ENV{VAR}` we already have the syntax for calling a ?function?. What is missing, is a command to define a function and a command to specify the return value of a function. Once we have this, it would be possible to define $LIST_LENGTH in the CMake language itself. And real functions with return values could make writing in CMake language much more easier. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From brad.king at kitware.com Tue Jan 22 10:37:17 2019 From: brad.king at kitware.com (Brad King) Date: Tue, 22 Jan 2019 10:37:17 -0500 Subject: [cmake-developers] real functions (was: $LIST_LENGTH{} syntax) In-Reply-To: References: <8B5B4D18-221C-46A5-83B9-7A8C80821D44@Robitzki.de> <1eebb310-2cb7-ba90-08de-ccb4c971a547@kitware.com> <5B569339-39AA-4CE3-AC7A-57D853347CEF@Robitzki.de> <377b97ce-6f62-a28a-4117-0d09391d0b77@kitware.com> <91A2CDCB-EC38-4493-BDE0-C9D2E9228899@Robitzki.de> <7dd53928-49f5-d61c-3ff0-e23b503824cb@kitware.com> Message-ID: <51e25921-5269-0f78-d596-209ac0f168a3@kitware.com> On 1/22/19 10:28 AM, Torsten at Robitzki.de wrote: > With `$CACHE{VAR}` and `$ENV{VAR}` we already have the syntax for calling a ?function?. No, there is no obvious way to pass arguments, handle nested quoting, etc. The language was not designed for that. That is a big can of worms I'd rather not open just to solve the list length problem which is already only 2 lines. > Once we have this, it would be possible to define $LIST_LENGTH in the CMake language Not as efficiently as a dedicated syntax for the only language construct we have that resembles a data structure. -Brad From Torsten at Robitzki.de Tue Jan 22 10:41:35 2019 From: Torsten at Robitzki.de (Torsten at Robitzki.de) Date: Tue, 22 Jan 2019 16:41:35 +0100 Subject: [cmake-developers] real functions (was: $LIST_LENGTH{} syntax) In-Reply-To: <51e25921-5269-0f78-d596-209ac0f168a3@kitware.com> References: <8B5B4D18-221C-46A5-83B9-7A8C80821D44@Robitzki.de> <1eebb310-2cb7-ba90-08de-ccb4c971a547@kitware.com> <5B569339-39AA-4CE3-AC7A-57D853347CEF@Robitzki.de> <377b97ce-6f62-a28a-4117-0d09391d0b77@kitware.com> <91A2CDCB-EC38-4493-BDE0-C9D2E9228899@Robitzki.de> <7dd53928-49f5-d61c-3ff0-e23b503824cb@kitware.com> <51e25921-5269-0f78-d596-209ac0f168a3@kitware.com> Message-ID: <62A5DAB7-280C-4A71-B7A9-5903A3587E5C@Robitzki.de> > Am 22.01.2019 um 16:37 schrieb Brad King : > > On 1/22/19 10:28 AM, Torsten at Robitzki.de wrote: >> With `$CACHE{VAR}` and `$ENV{VAR}` we already have the syntax for calling a ?function?. > > No, there is no obvious way to pass arguments, handle nested quoting, etc. Jep, you are right. I?ve overlooked that nested aspect. > The language was not designed for that. That is a big can of worms I'd rather > not open just to solve the list length problem which is already only 2 lines. Ok, I understand this. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From marc.chevrier at gmail.com Tue Jan 22 10:55:53 2019 From: marc.chevrier at gmail.com (Marc CHEVRIER) Date: Tue, 22 Jan 2019 16:55:53 +0100 Subject: [cmake-developers] real functions (was: $LIST_LENGTH{} syntax) In-Reply-To: <51e25921-5269-0f78-d596-209ac0f168a3@kitware.com> References: <8B5B4D18-221C-46A5-83B9-7A8C80821D44@Robitzki.de> <1eebb310-2cb7-ba90-08de-ccb4c971a547@kitware.com> <5B569339-39AA-4CE3-AC7A-57D853347CEF@Robitzki.de> <377b97ce-6f62-a28a-4117-0d09391d0b77@kitware.com> <91A2CDCB-EC38-4493-BDE0-C9D2E9228899@Robitzki.de> <7dd53928-49f5-d61c-3ff0-e23b503824cb@kitware.com> <51e25921-5269-0f78-d596-209ac0f168a3@kitware.com> Message-ID: I am not convince that the proposed syntax is a good idea because it introduce a new syntax just to solve one action on a list. What about introducing a syntax similar to the version comparison: ? LENGTH_EQUAL ? LENGTH_GREATER ? LENGTH_LOWER ? etc? To use it: if (my_list LENGTH_EQUAL 1) ? # do my stuff endif() Or introduce a more general syntax for list management as part of an expression: $LIST{,[,,?]} Where , and use same semantic as list command. To use it: of ($LIST{LENGTH,my_list} EQUAL 1) ? # do my stuff endif() The advantage of this syntax is extensibility: More can be added and more commands can be introduced (for example $STRING{?}). Le 22 janv. 2019 ? 16:37 +0100, Brad King via cmake-developers , a ?crit : > On 1/22/19 10:28 AM, Torsten at Robitzki.de wrote: > > With `$CACHE{VAR}` and `$ENV{VAR}` we already have the syntax for calling a ?function?. > > No, there is no obvious way to pass arguments, handle nested quoting, etc. > The language was not designed for that. That is a big can of worms I'd rather > not open just to solve the list length problem which is already only 2 lines. > > > Once we have this, it would be possible to define $LIST_LENGTH in the CMake language > > Not as efficiently as a dedicated syntax for the only language construct > we have that resembles a data structure. > > -Brad > -- > > 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-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Tue Jan 22 10:57:07 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 22 Jan 2019 10:57:07 -0500 Subject: [cmake-developers] $LIST_LENGTH{} syntax (was: Support for list length expression in if()-command?) In-Reply-To: References: <8B5B4D18-221C-46A5-83B9-7A8C80821D44@Robitzki.de> <1eebb310-2cb7-ba90-08de-ccb4c971a547@kitware.com> <5B569339-39AA-4CE3-AC7A-57D853347CEF@Robitzki.de> <377b97ce-6f62-a28a-4117-0d09391d0b77@kitware.com> <91A2CDCB-EC38-4493-BDE0-C9D2E9228899@Robitzki.de> <7dd53928-49f5-d61c-3ff0-e23b503824cb@kitware.com> <36327d7c10fdd6d783878d75482c4b9b@webmail-alfa3018.alfahosting-server.de> Message-ID: I like some syntax that looks like $LEN{}. I would love to keep the $...{ syntax open for future exentsion such as easy target property set/get ( $[prop_name]{target} ) . This seems to be okay as $ENV, and $CACHE only work on variables, so therefore adding $LEN that also only works on variables seems reasonable. On Tue, Jan 22, 2019 at 7:46 AM Brad King via cmake-developers wrote: > > On 1/22/19 7:40 AM, Daniel Franke wrote: > > Whats about a Syntax like > > > > ${list::LENGTH} > > That would require dispatch after matching `${VAR}` syntax, and > that lookup is one of the hottest paths according to profiling. > We already have $ENV{} and $CACHE{} syntax. > > -Brad > -- > > 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-developers From brad.king at kitware.com Tue Jan 22 11:03:26 2019 From: brad.king at kitware.com (Brad King) Date: Tue, 22 Jan 2019 11:03:26 -0500 Subject: [cmake-developers] $LIST_LENGTH{} syntax In-Reply-To: References: <8B5B4D18-221C-46A5-83B9-7A8C80821D44@Robitzki.de> <1eebb310-2cb7-ba90-08de-ccb4c971a547@kitware.com> <5B569339-39AA-4CE3-AC7A-57D853347CEF@Robitzki.de> <377b97ce-6f62-a28a-4117-0d09391d0b77@kitware.com> <91A2CDCB-EC38-4493-BDE0-C9D2E9228899@Robitzki.de> <7dd53928-49f5-d61c-3ff0-e23b503824cb@kitware.com> <51e25921-5269-0f78-d596-209ac0f168a3@kitware.com> Message-ID: On 1/22/19 10:55 AM, Marc CHEVRIER wrote: > What about introducing a syntax similar to the version comparison: > > * LENGTH_EQUAL > * LENGTH_GREATER > * LENGTH_LOWER > * etc? > > To use it: > if (my_list LENGTH_EQUAL 1) > ? # do my stuff > endif() That's where this thread started. Every new if() operator potentially requires a policy, and there may be other places that the length of a list is useful. > Or introduce a more general syntax for list management as part > of an expression: > $LIST{,[,,?]} > > Where , and use same semantic as list command. > To use it: > of ($LIST{LENGTH,my_list} EQUAL 1) > ? # do my stuff > endif() Yes, something more extensible would be fine. We need to be careful not to slow down the variable reference syntax parser though. -Brad From Torsten at Robitzki.de Tue Jan 22 13:31:43 2019 From: Torsten at Robitzki.de (Torsten at Robitzki.de) Date: Tue, 22 Jan 2019 19:31:43 +0100 Subject: [cmake-developers] $LIST_LENGTH{} syntax In-Reply-To: References: <8B5B4D18-221C-46A5-83B9-7A8C80821D44@Robitzki.de> <1eebb310-2cb7-ba90-08de-ccb4c971a547@kitware.com> <5B569339-39AA-4CE3-AC7A-57D853347CEF@Robitzki.de> <377b97ce-6f62-a28a-4117-0d09391d0b77@kitware.com> <91A2CDCB-EC38-4493-BDE0-C9D2E9228899@Robitzki.de> <7dd53928-49f5-d61c-3ff0-e23b503824cb@kitware.com> <51e25921-5269-0f78-d596-209ac0f168a3@kitware.com> Message-ID: > Am 22.01.2019 um 17:03 schrieb Brad King : > > Yes, something more extensible would be fine. We need to be careful > not to slow down the variable reference syntax parser though. Currently, the Code that evaluates the ${}-Syntax only evaluates the key, if the key is not an empty string: const char* cmCommandArgumentParserHelper::ExpandSpecialVariable( const char* key, const char* var) { if (!key) { return this->ExpandVariable(var); } if (!var) { return ""; } if (strcmp(key, "ENV") == 0) { std::string str; if (cmSystemTools::GetEnv(var, str)) { if (this->EscapeQuotes) { return this->AddString(cmSystemTools::EscapeQuotes(str)); } return this->AddString(str); } return ""; } if (strcmp(key, ?CACHE") == 0) { ? so, there seems to be no risk to slow down the ExpandVariable()-Path (but of cause, I would measure the difference). kind regards, Torsten -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From brad.king at kitware.com Tue Jan 22 13:59:29 2019 From: brad.king at kitware.com (Brad King) Date: Tue, 22 Jan 2019 13:59:29 -0500 Subject: [cmake-developers] $LIST_LENGTH{} syntax In-Reply-To: References: <8B5B4D18-221C-46A5-83B9-7A8C80821D44@Robitzki.de> <1eebb310-2cb7-ba90-08de-ccb4c971a547@kitware.com> <5B569339-39AA-4CE3-AC7A-57D853347CEF@Robitzki.de> <377b97ce-6f62-a28a-4117-0d09391d0b77@kitware.com> <91A2CDCB-EC38-4493-BDE0-C9D2E9228899@Robitzki.de> <7dd53928-49f5-d61c-3ff0-e23b503824cb@kitware.com> <51e25921-5269-0f78-d596-209ac0f168a3@kitware.com> Message-ID: <4bdda705-6a00-860a-95e6-2b6935ef2d34@kitware.com> On 1/22/19 1:31 PM, Torsten at Robitzki.de wrote: > Currently, the Code that evaluates the ${}-Syntax only evaluates the key > > const char* cmCommandArgumentParserHelper::ExpandSpecialVariable( That's the pre-CMP0053 impl. See cmMakefile::ExpandVariablesInStringNew for the modern impl. Only with CMP0053 set to NEW can we consider the new syntax. -Brad From ben.boeckel at kitware.com Tue Jan 22 13:59:31 2019 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 22 Jan 2019 13:59:31 -0500 Subject: [cmake-developers] $LIST_LENGTH{} syntax In-Reply-To: References: <1eebb310-2cb7-ba90-08de-ccb4c971a547@kitware.com> <5B569339-39AA-4CE3-AC7A-57D853347CEF@Robitzki.de> <377b97ce-6f62-a28a-4117-0d09391d0b77@kitware.com> <91A2CDCB-EC38-4493-BDE0-C9D2E9228899@Robitzki.de> <7dd53928-49f5-d61c-3ff0-e23b503824cb@kitware.com> <51e25921-5269-0f78-d596-209ac0f168a3@kitware.com> Message-ID: <20190122185931.GA848@megas.kitware.com> On Tue, Jan 22, 2019 at 19:31:43 +0100, Torsten at Robitzki.de wrote: > Currently, the Code that evaluates the ${}-Syntax only evaluates the key, if the key is not an empty string: > > const char* cmCommandArgumentParserHelper::ExpandSpecialVariable( > const char* key, const char* var) > { > if (!key) { > return this->ExpandVariable(var); > } > if (!var) { > return ""; > } > if (strcmp(key, "ENV") == 0) { > std::string str; > if (cmSystemTools::GetEnv(var, str)) { > if (this->EscapeQuotes) { > return this->AddString(cmSystemTools::EscapeQuotes(str)); > } > return this->AddString(str); > } > return ""; > } > if (strcmp(key, ?CACHE") == 0) { > > ? > > so, there seems to be no risk to slow down the ExpandVariable()-Path (but of cause, I would measure the difference). That's the old (pre-CMP0053) parser. The new code for handling the `$XXX{` parse switching is in `Source/cmMakefile.cxx:2810` (or so). The method is `cmMakefile::ExpandVariablesInStringNew`. It is very performance sensitive (i.e., the old parser is so slow compared to the new one that running the new one beside it doesn't really affect performance much and is what allows for CMP0053 warning messages). --Ben From venytch at gmail.com Thu Jan 24 11:42:04 2019 From: venytch at gmail.com (Venedict Tchistopolskii) Date: Thu, 24 Jan 2019 08:42:04 -0800 Subject: [cmake-developers] Compiling static/stand-alone CMake.exe Message-ID: Hey there! *Current toolchain file for compiling CMake using CMake (on WIndows):* SET(CMAKE_SYSTEM_NAME Windows) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY) *Unfortunately this konks out with:* CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: LIBMD_LIBRARY linked by target "cmTC_356fd" in directory D:/GitHub/custom_cmake/solutions_cmake/CMakeFiles/CMakeTmp *Trying to do so because building CMake without toolchain gives me the below; After I move cmake.exe to another directory:* CMake Error: Could not find CMAKE_ROOT !!! CMake has most likely not been installed correctly. Modules directory not found in Usage cmake [options] cmake [options] cmake [options] -S -B Specify a source directory to (re-)generate a build system for it in the current working directory. Specify an existing build directory to re-generate its build system. Run 'cmake --help' for more information. *Please advise!!* *VT* -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Thu Jan 24 12:09:58 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Thu, 24 Jan 2019 12:09:58 -0500 Subject: [cmake-developers] Compiling static/stand-alone CMake.exe In-Reply-To: References: Message-ID: <1548349798.24928.12.camel@kitware.com> Venedict, To relocate cmake.exe, it's not sufficient to just copy the executable - you have to install all of the modules along with it. You do this by running the "install" target. Given a path to where you want to put CMake, you would build it like this: cmake C:/Path/To/CMake/Source -DCMAKE_INSTALL_PREFIX=C:/Path/To/Where/I/Want/To/Install cmake --build . cmake --build . --target install This will install cmake.exe along with all of its dependencies. Kyle On Thu, 2019-01-24 at 08:42 -0800, Venedict Tchistopolskii wrote: > Hey there! > > Current toolchain file for compiling CMake using CMake (on WIndows): > SET(CMAKE_SYSTEM_NAME Windows) > set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) > set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) > set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) > set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) > set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY) > > Unfortunately this konks out with: > CMake Error: The following variables are used in this project, but > they are set to NOTFOUND. > Please set them or make sure they are set and tested correctly in the > CMake files: > LIBMD_LIBRARY > ??? linked by target "cmTC_356fd" in directory > D:/GitHub/custom_cmake/solutions_cmake/CMakeFiles/CMakeTmp > > Trying to do so because building CMake without toolchain gives me the > below; After I move cmake.exe to another directory: > CMake Error: Could not find CMAKE_ROOT !!! > CMake has most likely not been installed correctly. > Modules directory not found in > > Usage > > ? cmake [options] > ? cmake [options] > ? cmake [options] -S -B > > Specify a source directory to (re-)generate a build system for it in > the > current working directory.? Specify an existing build directory to > re-generate its build system. > > Run 'cmake --help' for more information. > > Please advise!! > > VT > > > --? > > 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/op > ensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Thu Jan 24 12:12:36 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Thu, 24 Jan 2019 12:12:36 -0500 Subject: [cmake-developers] Compiling static/stand-alone CMake.exe In-Reply-To: <1548349798.24928.12.camel@kitware.com> References: <1548349798.24928.12.camel@kitware.com> Message-ID: <1548349956.24928.14.camel@kitware.com> I forgot to mention - building it this way doesn't require the use of a toolchain file - it was in response to this: >?Trying to do so because building CMake without toolchain gives me the below; After I move cmake.exe to another directory: If you build it as I laid out below, you won't need a toolchain file. Hope this helps! Kyle On Thu, 2019-01-24 at 12:09 -0500, Kyle Edwards wrote: > Venedict, > > To relocate cmake.exe, it's not sufficient to just copy the > executable - you have to install all of the modules along with it. > You do this by running the "install" target. > > Given a path to where you want to put CMake, you would build it like > this: > > cmake C:/Path/To/CMake/Source > -DCMAKE_INSTALL_PREFIX=C:/Path/To/Where/I/Want/To/Install > cmake --build . > cmake --build . --target install > > This will install cmake.exe along with all of its dependencies. > > Kyle > > On Thu, 2019-01-24 at 08:42 -0800, Venedict Tchistopolskii wrote: > > Hey there! > > > > Current toolchain file for compiling CMake using CMake (on > > WIndows): > > SET(CMAKE_SYSTEM_NAME Windows) > > set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) > > set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) > > set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) > > set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) > > set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY) > > > > Unfortunately this konks out with: > > CMake Error: The following variables are used in this project, but > > they are set to NOTFOUND. > > Please set them or make sure they are set and tested correctly in > > the CMake files: > > LIBMD_LIBRARY > > ??? linked by target "cmTC_356fd" in directory > > D:/GitHub/custom_cmake/solutions_cmake/CMakeFiles/CMakeTmp > > > > Trying to do so because building CMake without toolchain gives me > > the below; After I move cmake.exe to another directory: > > CMake Error: Could not find CMAKE_ROOT !!! > > CMake has most likely not been installed correctly. > > Modules directory not found in > > > > Usage > > > > ? cmake [options] > > ? cmake [options] > > ? cmake [options] -S -B > > > > Specify a source directory to (re-)generate a build system for it > > in the > > current working directory.? Specify an existing build directory to > > re-generate its build system. > > > > Run 'cmake --help' for more information. > > > > Please advise!! > > > > VT > > > > > > --? > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: http://ww > > w.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-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From venytch at gmail.com Thu Jan 24 12:23:23 2019 From: venytch at gmail.com (Venedict Tchistopolskii) Date: Thu, 24 Jan 2019 09:23:23 -0800 Subject: [cmake-developers] Compiling static/stand-alone CMake.exe In-Reply-To: <1548349956.24928.14.camel@kitware.com> References: <1548349798.24928.12.camel@kitware.com> <1548349956.24928.14.camel@kitware.com> Message-ID: I was building it via VStudio and generating the solution via CMake, is that wrong? I need cmake-gui.exe to be built too, would that work with this install path setting? VT On Thu, Jan 24, 2019 at 9:12 AM Kyle Edwards wrote: > I forgot to mention - building it this way doesn't require the use of a > toolchain file - it was in response to this: > > > *Trying to do so because building CMake without toolchain gives me the > below; After I move cmake.exe to another directory:* > > If you build it as I laid out below, you won't need a toolchain file. Hope > this helps! > > Kyle > > > On Thu, 2019-01-24 at 12:09 -0500, Kyle Edwards wrote: > > Venedict, > > To relocate cmake.exe, it's not sufficient to just copy the executable - > you have to install all of the modules along with it. You do this by > running the "install" target. > > Given a path to where you want to put CMake, you would build it like this: > > cmake C:/Path/To/CMake/Source > -DCMAKE_INSTALL_PREFIX=C:/Path/To/Where/I/Want/To/Install > cmake --build . > cmake --build . --target install > > This will install cmake.exe along with all of its dependencies. > > Kyle > > On Thu, 2019-01-24 at 08:42 -0800, Venedict Tchistopolskii wrote: > > Hey there! > > *Current toolchain file for compiling CMake using CMake (on WIndows):* > SET(CMAKE_SYSTEM_NAME Windows) > set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) > set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) > set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) > set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) > set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY) > > *Unfortunately this konks out with:* > CMake Error: The following variables are used in this project, but they > are set to NOTFOUND. > Please set them or make sure they are set and tested correctly in the > CMake files: > LIBMD_LIBRARY > linked by target "cmTC_356fd" in directory > D:/GitHub/custom_cmake/solutions_cmake/CMakeFiles/CMakeTmp > > *Trying to do so because building CMake without toolchain gives me the > below; After I move cmake.exe to another directory:* > CMake Error: Could not find CMAKE_ROOT !!! > CMake has most likely not been installed correctly. > Modules directory not found in > > Usage > > cmake [options] > cmake [options] > cmake [options] -S -B > > Specify a source directory to (re-)generate a build system for it in the > current working directory. Specify an existing build directory to > re-generate its build system. > > Run 'cmake --help' for more information. > > > > *Please advise!!* > > *VT* > > > -- > > 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-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From venytch at gmail.com Thu Jan 24 12:27:00 2019 From: venytch at gmail.com (Venedict Tchistopolskii) Date: Thu, 24 Jan 2019 09:27:00 -0800 Subject: [cmake-developers] Compiling static/stand-alone CMake.exe In-Reply-To: References: <1548349798.24928.12.camel@kitware.com> <1548349956.24928.14.camel@kitware.com> Message-ID: Er, lemme clarify. Can cmake-gui.exe be built along with cmake if using the install path setting? I currently use windeployqt to handle gui dependencies. On Thu, Jan 24, 2019 at 9:23 AM Venedict Tchistopolskii wrote: > I was building it via VStudio and generating the solution via CMake, is > that wrong? > > I need cmake-gui.exe to be built too, would that work with this install > path setting? > > VT > > On Thu, Jan 24, 2019 at 9:12 AM Kyle Edwards > wrote: > >> I forgot to mention - building it this way doesn't require the use of a >> toolchain file - it was in response to this: >> >> > *Trying to do so because building CMake without toolchain gives me the >> below; After I move cmake.exe to another directory:* >> >> If you build it as I laid out below, you won't need a toolchain file. >> Hope this helps! >> >> Kyle >> >> >> On Thu, 2019-01-24 at 12:09 -0500, Kyle Edwards wrote: >> >> Venedict, >> >> To relocate cmake.exe, it's not sufficient to just copy the executable - >> you have to install all of the modules along with it. You do this by >> running the "install" target. >> >> Given a path to where you want to put CMake, you would build it like this: >> >> cmake C:/Path/To/CMake/Source >> -DCMAKE_INSTALL_PREFIX=C:/Path/To/Where/I/Want/To/Install >> cmake --build . >> cmake --build . --target install >> >> This will install cmake.exe along with all of its dependencies. >> >> Kyle >> >> On Thu, 2019-01-24 at 08:42 -0800, Venedict Tchistopolskii wrote: >> >> Hey there! >> >> *Current toolchain file for compiling CMake using CMake (on WIndows):* >> SET(CMAKE_SYSTEM_NAME Windows) >> set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) >> set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) >> set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) >> set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) >> set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY) >> >> *Unfortunately this konks out with:* >> CMake Error: The following variables are used in this project, but they >> are set to NOTFOUND. >> Please set them or make sure they are set and tested correctly in the >> CMake files: >> LIBMD_LIBRARY >> linked by target "cmTC_356fd" in directory >> D:/GitHub/custom_cmake/solutions_cmake/CMakeFiles/CMakeTmp >> >> *Trying to do so because building CMake without toolchain gives me the >> below; After I move cmake.exe to another directory:* >> CMake Error: Could not find CMAKE_ROOT !!! >> CMake has most likely not been installed correctly. >> Modules directory not found in >> >> Usage >> >> cmake [options] >> cmake [options] >> cmake [options] -S -B >> >> Specify a source directory to (re-)generate a build system for it in the >> current working directory. Specify an existing build directory to >> re-generate its build system. >> >> Run 'cmake --help' for more information. >> >> >> >> *Please advise!!* >> >> *VT* >> >> >> -- >> >> 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-developers >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Thu Jan 24 12:30:20 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Thu, 24 Jan 2019 12:30:20 -0500 Subject: [cmake-developers] Compiling static/stand-alone CMake.exe In-Reply-To: References: <1548349798.24928.12.camel@kitware.com> <1548349956.24928.14.camel@kitware.com> Message-ID: <1548351020.24928.18.camel@kitware.com> On Thu, 2019-01-24 at 09:23 -0800, Venedict Tchistopolskii wrote: > I was building it via VStudio and generating the solution via CMake, > is that wrong? Nope! You're building it just fine. The only problem is in the installation - you were installing cmake.exe without all of the external files it needs. Running cmake --build . --target install will take care of this for you. > I need cmake-gui.exe to be built too, would that work with this install path setting? Yes. You just need to make sure BUILD_QtDialog is turned ON: cmake C:/Path/To/CMake/Source -DCMAKE_INSTALL_PREFIX=C:/Path/To/Where/I/Want/To/Install -DBUILD_QtDialog=ON Keep in mind that you will need a Qt installation to build cmake-gui. Kyle > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Thu Jan 24 12:36:18 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Thu, 24 Jan 2019 12:36:18 -0500 Subject: [cmake-developers] Compiling static/stand-alone CMake.exe In-Reply-To: References: <1548349798.24928.12.camel@kitware.com> <1548349956.24928.14.camel@kitware.com> Message-ID: <1548351378.24928.21.camel@kitware.com> On Thu, 2019-01-24 at 09:27 -0800, Venedict Tchistopolskii wrote: > Er, lemme clarify. > > Can cmake-gui.exe be built along with cmake if using the install path > setting? I currently use windeployqt to handle gui dependencies. Yes, like I mentioned, just build with BUILD_QtDialog=ON. You can then run windeployqt after running cmake --build . --target install: cmake --build . --target install windeployqt C:/Path/To/Where/I/Want/To/Install/bin/cmake.exe Kyle > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Thu Jan 24 12:37:26 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Thu, 24 Jan 2019 12:37:26 -0500 Subject: [cmake-developers] Compiling static/stand-alone CMake.exe In-Reply-To: <1548351378.24928.21.camel@kitware.com> References: <1548349798.24928.12.camel@kitware.com> <1548349956.24928.14.camel@kitware.com> <1548351378.24928.21.camel@kitware.com> Message-ID: <1548351446.24928.22.camel@kitware.com> On Thu, 2019-01-24 at 12:36 -0500, Kyle Edwards wrote: > cmake --build . --target install > windeployqt C:/Path/To/Where/I/Want/To/Install/bin/cmake.exe Oops - this should obviously be C:/Path/To/Where/I/Want/To/Install/bin/cmake-gui.exe. Kyle -------------- next part -------------- An HTML attachment was scrubbed... URL: From venytch at gmail.com Thu Jan 24 15:25:23 2019 From: venytch at gmail.com (Venedict Tchistopolskii) Date: Thu, 24 Jan 2019 12:25:23 -0800 Subject: [cmake-developers] Compiling static/stand-alone CMake.exe In-Reply-To: <1548351446.24928.22.camel@kitware.com> References: <1548349798.24928.12.camel@kitware.com> <1548349956.24928.14.camel@kitware.com> <1548351378.24928.21.camel@kitware.com> <1548351446.24928.22.camel@kitware.com> Message-ID: The install command auto-installs release right? How do I trigger this 'install' from VStudio? Is building in VStudio enough before install? e.g. generate solution -> build in VStudio -> run install command in CLI? Just not sure on the proper flow because I use VStudio to debug/modify/test CMake. Additionally with this setup cmake-gui.exe can't find Qt5widgets etc. no matter what I do..... It finds it if I use the .exe built by VStudio. On Thu, Jan 24, 2019 at 9:37 AM Kyle Edwards wrote: > On Thu, 2019-01-24 at 12:36 -0500, Kyle Edwards wrote: > > cmake --build . --target install > windeployqt C:/Path/To/Where/I/Want/To/Install/bin/cmake.exe > > > Oops - this should obviously be > C:/Path/To/Where/I/Want/To/Install/bin/cmake-gui.exe. > > Kyle > -------------- next part -------------- An HTML attachment was scrubbed... URL: From venytch at gmail.com Thu Jan 24 15:31:04 2019 From: venytch at gmail.com (Venedict Tchistopolskii) Date: Thu, 24 Jan 2019 12:31:04 -0800 Subject: [cmake-developers] Compiling static/stand-alone CMake.exe In-Reply-To: References: <1548349798.24928.12.camel@kitware.com> <1548349956.24928.14.camel@kitware.com> <1548351378.24928.21.camel@kitware.com> <1548351446.24928.22.camel@kitware.com> Message-ID: Nevermind, fixed the cmake-gui. Would be nice to know how to triger the proper install/release config from VStudio, atm I do this: cmake . --target install --config Release On Thu, Jan 24, 2019 at 12:25 PM Venedict Tchistopolskii wrote: > The install command auto-installs release right? > How do I trigger this 'install' from VStudio? > Is building in VStudio enough before install? > e.g. generate solution -> build in VStudio -> run install command in CLI? > Just not sure on the proper flow because I use VStudio to > debug/modify/test CMake. > > Additionally with this setup cmake-gui.exe can't find Qt5widgets etc. no > matter what I do..... > > It finds it if I use the .exe built by VStudio. > > On Thu, Jan 24, 2019 at 9:37 AM Kyle Edwards > wrote: > >> On Thu, 2019-01-24 at 12:36 -0500, Kyle Edwards wrote: >> >> cmake --build . --target install >> windeployqt C:/Path/To/Where/I/Want/To/Install/bin/cmake.exe >> >> >> Oops - this should obviously be >> C:/Path/To/Where/I/Want/To/Install/bin/cmake-gui.exe. >> >> Kyle >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Thu Jan 24 15:32:59 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Thu, 24 Jan 2019 15:32:59 -0500 Subject: [cmake-developers] Compiling static/stand-alone CMake.exe In-Reply-To: References: <1548349798.24928.12.camel@kitware.com> <1548349956.24928.14.camel@kitware.com> <1548351378.24928.21.camel@kitware.com> <1548351446.24928.22.camel@kitware.com> Message-ID: <1548361979.24928.25.camel@kitware.com> On Thu, 2019-01-24 at 12:25 -0800, Venedict Tchistopolskii wrote: > The install command auto-installs release right? > How do I trigger this 'install' from VStudio? > Is building in VStudio enough before install? > e.g. generate solution -> build in VStudio -> run install > command in CLI? Yes, this will work. > Just not sure on the proper flow because I use VStudio to debug/modify/test CMake. Usually debugging etc. is done on the .exe inside the build tree, rather than the install tree. > Additionally with this setup cmake-gui.exe can't find Qt5widgets etc. no matter what I do..... You mean at build-time, or at runtime? > It finds it if I use the .exe built by VStudio. Does the one in VStudio have all the Qt DLLs beside it in the directory? Kyle > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Thu Jan 24 15:36:33 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Thu, 24 Jan 2019 15:36:33 -0500 Subject: [cmake-developers] Compiling static/stand-alone CMake.exe In-Reply-To: References: <1548349798.24928.12.camel@kitware.com> <1548349956.24928.14.camel@kitware.com> <1548351378.24928.21.camel@kitware.com> <1548351446.24928.22.camel@kitware.com> Message-ID: <1548362193.24928.28.camel@kitware.com> On Thu, 2019-01-24 at 12:31 -0800, Venedict Tchistopolskii wrote: > Nevermind, fixed the cmake-gui. Ah OK, then disregard my response. > Would be nice to know how to triger the proper install/release config from VStudio, atm I do this: > cmake . --target install --config Release This looks correct for doing it on the command line. The VStudio solution should have an "INSTALL" project which does what you want. Kyle > -------------- next part -------------- An HTML attachment was scrubbed... URL: From venytch at gmail.com Thu Jan 24 15:58:31 2019 From: venytch at gmail.com (Venedict Tchistopolskii) Date: Thu, 24 Jan 2019 12:58:31 -0800 Subject: [cmake-developers] Compiling static/stand-alone CMake.exe In-Reply-To: <1548362193.24928.28.camel@kitware.com> References: <1548349798.24928.12.camel@kitware.com> <1548349956.24928.14.camel@kitware.com> <1548351378.24928.21.camel@kitware.com> <1548351446.24928.22.camel@kitware.com> <1548362193.24928.28.camel@kitware.com> Message-ID: *Thank you! Sorry for the mess. Builds now :)* *Just an FYI, I'm using this Preload.cmake file:* ## Required to build GUI set(CMAKE_PREFIX_PATH "C:\\Qt\\5.12.0\\msvc2017_64" CACHE STRING "" FORCE) set(BUILD_QtDialog ON CACHE BOOL "" FORCE) ## Standerdizing build options for 64-bit CMake set(CMAKE_GENERATOR "Visual Studio 15 2017 Win64" CACHE INTERNAL "" FORCE) set(CMAKE_INSTALL_PREFIX "${CMAKE_CURRENT_LIST_DIR}/standalone" CACHE STRING "" FORCE) *Makes it easier to standardize.* *VT* On Thu, Jan 24, 2019 at 12:36 PM Kyle Edwards wrote: > On Thu, 2019-01-24 at 12:31 -0800, Venedict Tchistopolskii wrote: > > Nevermind, fixed the cmake-gui. > > > Ah OK, then disregard my response. > > Would be nice to know how to triger the proper install/release config from > VStudio, atm I do this: > cmake . --target install --config Release > > > This looks correct for doing it on the command line. > > The VStudio solution should have an "INSTALL" project which does what you > want. > > Kyle > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From venytch at gmail.com Thu Jan 24 17:33:31 2019 From: venytch at gmail.com (Venedict Tchistopolskii) Date: Thu, 24 Jan 2019 14:33:31 -0800 Subject: [cmake-developers] Controlling CMake GUI source/build directory from CLI Message-ID: Basically I want to launch the CMake GUI and pass in source/build directories through the CLI, overriding whatever it has at the moment. Is that possible? I don't get where it's picking up the previously touched source build but I want to override it consistently. E.g. cmake-gui.exe -HXXXX -BXXXX won't work..... This is for a project wrapper that handles CMake launch and preparation. VT -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.goesswein at eeas.at Fri Jan 25 03:18:33 2019 From: matthias.goesswein at eeas.at (=?UTF-8?Q?G=c3=b6=c3=9fwein_Matthias_/_eeas_gmbh?=) Date: Fri, 25 Jan 2019 09:18:33 +0100 Subject: [cmake-developers] Controlling CMake GUI source/build directory from CLI In-Reply-To: References: Message-ID: Dear Venedict, Yes, that ist possible. Basically the syntax for cmake-gui is: cmake-gui [] ( | ) So you can either pass a source directory or a build directory where cmake was already run. If you pass the path to the source directory as parameter, then cmake uses the current directory as build directory. So you can set both by changing to the build directory on the shell and run cmake-gui with the source-directory as parameter from there. However, the manual does not describe this behavior, maybe it should be mentioned there. (https://cmake.org/cmake/help/v3.13/manual/cmake-gui.1.html) Best regards, Matthias. Am 24.01.2019 um 23:33 schrieb Venedict Tchistopolskii: > Basically I want to launch the CMake GUI and pass in source/build > directories through the CLI, overriding whatever it has at the moment. > > Is that possible? I don't get where it's picking up the previously > touched source build but I want to override it consistently. > > E.g. cmake-gui.exe -HXXXX -BXXXX won't work..... > > This is for a project wrapper that handles CMake launch and preparation. > > VT > From kyle.edwards at kitware.com Fri Jan 25 09:52:29 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Fri, 25 Jan 2019 09:52:29 -0500 Subject: [cmake-developers] Controlling CMake GUI source/build directory from CLI In-Reply-To: References: Message-ID: <1548427949.24928.30.camel@kitware.com> On Fri, 2019-01-25 at 09:18 +0100, G??wein Matthias / eeas gmbh wrote: > However, the manual does not describe this behavior, maybe it should > be > mentioned there. > (https://cmake.org/cmake/help/v3.13/manual/cmake-gui.1.html) Even better, perhaps we should add explicit -B and -S options the way cmake and ccmake already do. Kyle From venytch at gmail.com Fri Jan 25 11:10:07 2019 From: venytch at gmail.com (Venedict Tchistopolskii) Date: Fri, 25 Jan 2019 08:10:07 -0800 Subject: [cmake-developers] Controlling CMake GUI source/build directory from CLI In-Reply-To: <1548427949.24928.30.camel@kitware.com> References: <1548427949.24928.30.camel@kitware.com> Message-ID: Actually that doesn't work..... *cmake-gui.exe "D:/GitHub/SOURCE" "D:/GitHub/SOURCE/solutions_cmake/win64"* Ignores both options, but *cmake-gui.exe "D:/GitHub/SOURCE"* Uses current directory as noted. Why? Syntax wrong or something? VT On Fri, Jan 25, 2019 at 6:52 AM Kyle Edwards wrote: > On Fri, 2019-01-25 at 09:18 +0100, G??wein Matthias / eeas gmbh wrote: > > However, the manual does not describe this behavior, maybe it should > > be > > mentioned there. > > (https://cmake.org/cmake/help/v3.13/manual/cmake-gui.1.html) > > Even better, perhaps we should add explicit -B and -S options the way > cmake and ccmake already do. > > Kyle > -------------- next part -------------- An HTML attachment was scrubbed... URL: From venytch at gmail.com Fri Jan 25 11:36:22 2019 From: venytch at gmail.com (Venedict Tchistopolskii) Date: Fri, 25 Jan 2019 08:36:22 -0800 Subject: [cmake-developers] Undocumented CMAKE_AUTOMOC_RELAXED_MODE changes in 3.13 Message-ID: When updating the project CMake from 3.12 to 3.13, *CMAKE_AUTOMOC_RELAXED_MODE* stops including certain generated moc files. Had to switch to *CMAKE_AUTOMOC *to get them included.....strange functionality on the part of CMake. Can't find any documentation on these changes, and if/how they were touched at all. VT -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Fri Jan 25 11:56:20 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Fri, 25 Jan 2019 11:56:20 -0500 Subject: [cmake-developers] Controlling CMake GUI source/build directory from CLI In-Reply-To: References: <1548427949.24928.30.camel@kitware.com> Message-ID: <1548435380.24928.32.camel@kitware.com> Venedict, Currently, cmake-gui only lets you specify a build or source directory, not both. I've opened?https://gitlab.kitware.com/cmake/cmake/merge_requests/2863? to add explicit -S and -B options to cmake-gui, which will allow you to specify both. Kyle On Fri, 2019-01-25 at 08:10 -0800, Venedict Tchistopolskii wrote: > Actually that doesn't work..... > cmake-gui.exe "D:/GitHub/SOURCE" > "D:/GitHub/SOURCE/solutions_cmake/win64" > > Ignores both options, but > cmake-gui.exe "D:/GitHub/SOURCE" > > Uses current directory as noted. Why? Syntax wrong or something? > > VT > > > On Fri, Jan 25, 2019 at 6:52 AM Kyle Edwards > m> wrote: > > On Fri, 2019-01-25 at 09:18 +0100, G??wein Matthias / eeas gmbh > > wrote: > > > However, the manual does not describe this behavior, maybe it > > should > > > be > > > mentioned there. > > > (https://cmake.org/cmake/help/v3.13/manual/cmake-gui.1.html) > > > > Even better, perhaps we should add explicit -B and -S options the > > way > > cmake and ccmake already do. > > > > Kyle > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From seblist at xwmw.org Fri Jan 25 13:20:02 2019 From: seblist at xwmw.org (Sebastian Holtermann) Date: Fri, 25 Jan 2019 19:20:02 +0100 Subject: [cmake-developers] Undocumented CMAKE_AUTOMOC_RELAXED_MODE changes in 3.13 In-Reply-To: References: Message-ID: <3286787.Ds2zr2rfzU@blauwal> Am Freitag, 25. Januar 2019, 17:36:22 CET schrieb Venedict Tchistopolskii: > When updating the project CMake from 3.12 to 3.13, > *CMAKE_AUTOMOC_RELAXED_MODE* stops including certain generated moc files. > > Had to switch to *CMAKE_AUTOMOC *to get them included.....strange > functionality on the part of CMake. > > Can't find any documentation on these changes, and if/how they were touched > at all. This isn't an intentional behavior change. Could you provide a minimal example that reproduces the problem? Also please feel free to open an issue here: https://gitlab.kitware.com/cmake/cmake/issues -Sebastian From venytch at gmail.com Fri Jan 25 15:07:27 2019 From: venytch at gmail.com (Venedict Tchistopolskii) Date: Fri, 25 Jan 2019 12:07:27 -0800 Subject: [cmake-developers] Undocumented CMAKE_AUTOMOC_RELAXED_MODE changes in 3.13 In-Reply-To: <3286787.Ds2zr2rfzU@blauwal> References: <3286787.Ds2zr2rfzU@blauwal> Message-ID: Unfortunately the project is fairly, uhm, large.....no small sample sorry. I'm not too familiar with the moc setup either, only reason I touched it is because it started failing after the CMake version update. If using relaxed mode, the moc files get generated but aren't included. So the standard "QT_OBJECT" setup is being detected but not added to VStudio v15.6.7 64 bit. It does use a fairly old QT version, QT 5.6. VT On Fri, Jan 25, 2019 at 10:49 AM Sebastian Holtermann wrote: > Am Freitag, 25. Januar 2019, 17:36:22 CET schrieb Venedict Tchistopolskii: > > When updating the project CMake from 3.12 to 3.13, > > *CMAKE_AUTOMOC_RELAXED_MODE* stops including certain generated moc files. > > > > Had to switch to *CMAKE_AUTOMOC *to get them included.....strange > > functionality on the part of CMake. > > > > Can't find any documentation on these changes, and if/how they were > touched > > at all. > > This isn't an intentional behavior change. > Could you provide a minimal example that reproduces the problem? > > Also please feel free to open an issue here: > https://gitlab.kitware.com/cmake/cmake/issues > > -Sebastian > > > > -- > > 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-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From venytch at gmail.com Fri Jan 25 15:55:34 2019 From: venytch at gmail.com (Venedict Tchistopolskii) Date: Fri, 25 Jan 2019 12:55:34 -0800 Subject: [cmake-developers] Controlling CMake GUI source/build directory from CLI In-Reply-To: <1548435380.24928.32.camel@kitware.com> References: <1548427949.24928.30.camel@kitware.com> <1548435380.24928.32.camel@kitware.com> Message-ID: Cherry picked and tested. Works great, thank you! Now, if only the source/build path would stick around, without requiring config to be triggered. :P On Fri, Jan 25, 2019 at 8:56 AM Kyle Edwards wrote: > Venedict, > > Currently, cmake-gui only lets you specify a build or source directory, > not both. > > I've opened https://gitlab.kitware.com/cmake/cmake/merge_requests/2863 to > add explicit -S and -B options to cmake-gui, which will allow you to > specify both. > > Kyle > > On Fri, 2019-01-25 at 08:10 -0800, Venedict Tchistopolskii wrote: > > Actually that doesn't work..... > *cmake-gui.exe "D:/GitHub/SOURCE" "D:/GitHub/SOURCE/solutions_cmake/win64"* > > Ignores both options, but > *cmake-gui.exe "D:/GitHub/SOURCE"* > > Uses current directory as noted. Why? Syntax wrong or something? > > VT > > > On Fri, Jan 25, 2019 at 6:52 AM Kyle Edwards > wrote: > > On Fri, 2019-01-25 at 09:18 +0100, G??wein Matthias / eeas gmbh wrote: > > However, the manual does not describe this behavior, maybe it should > > be > > mentioned there. > > (https://cmake.org/cmake/help/v3.13/manual/cmake-gui.1.html) > > Even better, perhaps we should add explicit -B and -S options the way > cmake and ccmake already do. > > Kyle > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Fri Jan 25 16:19:00 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Fri, 25 Jan 2019 16:19:00 -0500 Subject: [cmake-developers] Controlling CMake GUI source/build directory from CLI In-Reply-To: References: <1548427949.24928.30.camel@kitware.com> <1548435380.24928.32.camel@kitware.com> Message-ID: <1548451140.24928.36.camel@kitware.com> On Fri, 2019-01-25 at 12:55 -0800, Venedict Tchistopolskii wrote: > Cherry picked and tested. Works great, thank you! Great, glad to hear it! > Now, if only the source/build path would stick around, without requiring config to be triggered. :P Can you clarify what you mean by this? Kyle > -------------- next part -------------- An HTML attachment was scrubbed... URL: From venytch at gmail.com Fri Jan 25 16:23:34 2019 From: venytch at gmail.com (Venedict Tchistopolskii) Date: Fri, 25 Jan 2019 13:23:34 -0800 Subject: [cmake-developers] Controlling CMake GUI source/build directory from CLI In-Reply-To: <1548451140.24928.36.camel@kitware.com> References: <1548427949.24928.30.camel@kitware.com> <1548435380.24928.32.camel@kitware.com> <1548451140.24928.36.camel@kitware.com> Message-ID: Get 2 CMake projects. Get CMake GUI to 'configure' one of them. Close/re-open and it will automatically point to this configured project source and build locations, regardless of what build/version/cmake-gui.exe you use. Run a different cmake-gui.exe through the CLI, passing in source and build locations. It will be properly load these instead of the 'last configured project' now. Now close it, without configuring, and re-open it normally without CLI overrides. Now it'll load the original project as if you've never set it to a different source/build location. tl;dr CMake loads the last-configured source/bin directory by default. If you don't configure (or pass override through CLI) it will keep loading the same project. VT On Fri, Jan 25, 2019 at 1:19 PM Kyle Edwards wrote: > On Fri, 2019-01-25 at 12:55 -0800, Venedict Tchistopolskii wrote: > > Cherry picked and tested. Works great, thank you! > > > Great, glad to hear it! > > Now, if only the source/build path would stick around, without requiring > config to be triggered. :P > > > Can you clarify what you mean by this? > > Kyle > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Fri Jan 25 16:59:14 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Fri, 25 Jan 2019 16:59:14 -0500 Subject: [cmake-developers] Controlling CMake GUI source/build directory from CLI In-Reply-To: References: <1548427949.24928.30.camel@kitware.com> <1548435380.24928.32.camel@kitware.com> <1548451140.24928.36.camel@kitware.com> Message-ID: <1548453554.24928.42.camel@kitware.com> On Fri, 2019-01-25 at 13:23 -0800, Venedict Tchistopolskii wrote: > Get 2 CMake projects. > > Get CMake GUI to 'configure' one of them. Close/re-open and it will > automatically point to this configured project source and build > locations, regardless of what build/version/cmake-gui.exe you use.? > > Run a different cmake-gui.exe through the CLI, passing in source and > build locations. It will be properly load these instead of the 'last > configured project' now. > > Now close it, without configuring, and re-open it normally without > CLI overrides. Now it'll load the original project as if you've never > set it to a different source/build location. > > tl;dr CMake loads the last-configured source/bin directory by > default. If you don't configure (or pass override through CLI) it > will keep loading the same project. Ah, I see what you mean. Saving the build path is easy: just add the command-line path to the cache of build directories on startup as well as at configure time. Saving the source path is more difficult. The GUI gets the source directory by scanning the files in the build directory. If the build directory hasn't been generated yet, then the GUI will have no idea where to find the source directory, unless we start caching source directories as well. I think, as you noted, you're better off just triggering "Configure" before closing the dialog. Kyle > -------------- next part -------------- An HTML attachment was scrubbed... URL: From venytch at gmail.com Fri Jan 25 17:06:02 2019 From: venytch at gmail.com (Venedict Tchistopolskii) Date: Fri, 25 Jan 2019 14:06:02 -0800 Subject: [cmake-developers] Controlling CMake GUI source/build directory from CLI In-Reply-To: <1548453554.24928.42.camel@kitware.com> References: <1548427949.24928.30.camel@kitware.com> <1548435380.24928.32.camel@kitware.com> <1548451140.24928.36.camel@kitware.com> <1548453554.24928.42.camel@kitware.com> Message-ID: Could you clarify on saving the build-directory section? I'm not sure how it knows which cache or build directory to load. In my setup here the issue I noted applies even if build directory is generated on both projects/etc. VT On Fri, Jan 25, 2019 at 1:59 PM Kyle Edwards wrote: > On Fri, 2019-01-25 at 13:23 -0800, Venedict Tchistopolskii wrote: > > Get 2 CMake projects. > > Get CMake GUI to 'configure' one of them. Close/re-open and it will > automatically point to this configured project source and build locations, > regardless of what build/version/cmake-gui.exe you use. > > Run a different cmake-gui.exe through the CLI, passing in source and build > locations. It will be properly load these instead of the 'last configured > project' now. > > Now close it, without configuring, and re-open it normally without CLI > overrides. Now it'll load the original project as if you've never set it to > a different source/build location. > > tl;dr CMake loads the last-configured source/bin directory by default. If > you don't configure (or pass override through CLI) it will keep loading the > same project. > > > Ah, I see what you mean. > > Saving the build path is easy: just add the command-line path to the cache > of build directories on startup as well as at configure time. > > Saving the source path is more difficult. The GUI gets the source > directory by scanning the files in the build directory. If the build > directory hasn't been generated yet, then the GUI will have no idea where > to find the source directory, unless we start caching source directories as > well. > > I think, as you noted, you're better off just triggering "Configure" > before closing the dialog. > > Kyle > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Fri Jan 25 17:48:35 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Fri, 25 Jan 2019 17:48:35 -0500 Subject: [cmake-developers] Controlling CMake GUI source/build directory from CLI In-Reply-To: References: <1548427949.24928.30.camel@kitware.com> <1548435380.24928.32.camel@kitware.com> <1548451140.24928.36.camel@kitware.com> <1548453554.24928.42.camel@kitware.com> Message-ID: <1548456515.24928.45.camel@kitware.com> On Fri, 2019-01-25 at 14:06 -0800, Venedict Tchistopolskii wrote: > Could you clarify on saving the build-directory section? > > I'm not sure how it knows which cache or build directory to load. In > my setup here the issue I noted applies even if build directory is > generated on both projects/etc. > > VT As a convenience, cmake-gui uses a QSettings object to store the last few build directories that it configured. These directories are populated in the build directory dropdown menu. The source directories are not stored in QSettings at all, but instead extracted from the build directories. If the build directory hasn't been configured, then CMake has no way of knowing what source directory to pick. Kyle > -------------- next part -------------- An HTML attachment was scrubbed... URL: From venytch at gmail.com Fri Jan 25 17:51:40 2019 From: venytch at gmail.com (Venedict Tchistopolskii) Date: Fri, 25 Jan 2019 14:51:40 -0800 Subject: [cmake-developers] Controlling CMake GUI source/build directory from CLI In-Reply-To: <1548456515.24928.45.camel@kitware.com> References: <1548427949.24928.30.camel@kitware.com> <1548435380.24928.32.camel@kitware.com> <1548451140.24928.36.camel@kitware.com> <1548453554.24928.42.camel@kitware.com> <1548456515.24928.45.camel@kitware.com> Message-ID: Gagh I'm stupid, missed the drop down, thanks for clarifying! Much better now :) VT On Fri, Jan 25, 2019 at 2:48 PM Kyle Edwards wrote: > On Fri, 2019-01-25 at 14:06 -0800, Venedict Tchistopolskii wrote: > > Could you clarify on saving the build-directory section? > > I'm not sure how it knows which cache or build directory to load. In my > setup here the issue I noted applies even if build directory is generated > on both projects/etc. > > VT > > > As a convenience, cmake-gui uses a QSettings object to store the last few > build directories that it configured. These directories are populated in > the build directory dropdown menu. > > The source directories are not stored in QSettings at all, but instead > extracted from the build directories. If the build directory hasn't been > configured, then CMake has no way of knowing what source directory to pick. > > Kyle > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From venytch at gmail.com Fri Jan 25 21:27:08 2019 From: venytch at gmail.com (Venedict Tchistopolskii) Date: Fri, 25 Jan 2019 18:27:08 -0800 Subject: [cmake-developers] Undocumented CMAKE_AUTOMOC_RELAXED_MODE changes in 3.13 In-Reply-To: References: <3286787.Ds2zr2rfzU@blauwal> Message-ID: Actually, debugged a lot more and found this! The first CMake generation pass: Generates but no inclusion *Forcing a second pass makes it include the newly generated moc'* It says *"AutoMoc: Generating 'XXXXX' because the MOC settings changed"* I'm not too clear on why this is happening, any ideas on how to fix it, or force it to reload whatever 'moc settings' are changing? Note: This affects both relaxed and non-relaxed mode, my fix was a dummy because it involved regenerating cmake (ofc)....which is the actual solution. VT On Fri, Jan 25, 2019 at 12:07 PM Venedict Tchistopolskii wrote: > Unfortunately the project is fairly, uhm, large.....no small sample sorry. > > I'm not too familiar with the moc setup either, only reason I touched it > is because it started failing after the CMake version update. > > If using relaxed mode, the moc files get generated but aren't included. So > the standard "QT_OBJECT" setup is being detected but not added to VStudio > v15.6.7 64 bit. > > It does use a fairly old QT version, QT 5.6. > > VT > > On Fri, Jan 25, 2019 at 10:49 AM Sebastian Holtermann > wrote: > >> Am Freitag, 25. Januar 2019, 17:36:22 CET schrieb Venedict Tchistopolskii: >> > When updating the project CMake from 3.12 to 3.13, >> > *CMAKE_AUTOMOC_RELAXED_MODE* stops including certain generated moc >> files. >> > >> > Had to switch to *CMAKE_AUTOMOC *to get them included.....strange >> > functionality on the part of CMake. >> > >> > Can't find any documentation on these changes, and if/how they were >> touched >> > at all. >> >> This isn't an intentional behavior change. >> Could you provide a minimal example that reproduces the problem? >> >> Also please feel free to open an issue here: >> https://gitlab.kitware.com/cmake/cmake/issues >> >> -Sebastian >> >> >> >> -- >> >> 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-developers >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From seblist at xwmw.org Mon Jan 28 08:38:57 2019 From: seblist at xwmw.org (Sebastian Holtermann) Date: Mon, 28 Jan 2019 14:38:57 +0100 Subject: [cmake-developers] Undocumented CMAKE_AUTOMOC_RELAXED_MODE changes in 3.13 In-Reply-To: References: Message-ID: <1936283.oGWZgicvf1@blauwal> Am Samstag, 26. Januar 2019, 03:27:08 CET schrieb Venedict Tchistopolskii: > Actually, debugged a lot more and found this! > > The first CMake generation pass: Generates but no inclusion > > > > *Forcing a second pass makes it include the newly generated moc'* > It says *"AutoMoc: Generating 'XXXXX' because the MOC settings changed"* > > I'm not too clear on why this is happening, any ideas on how to fix it, or > force it to reload whatever 'moc settings' are changing? > > Note: This affects both relaxed and non-relaxed mode, my fix was a dummy > because it involved regenerating cmake (ofc)....which is the actual > solution. > > VT There already is an issue reported that seems related: https://gitlab.kitware.com/cmake/cmake/issues/17456 I'm not a Windows/VS developer and can't help much about it, sorry. If someone else is interested in this issue, please assist. -Sebastian From venytch at gmail.com Tue Jan 29 01:06:01 2019 From: venytch at gmail.com (Venedict Tchistopolskii) Date: Mon, 28 Jan 2019 22:06:01 -0800 Subject: [cmake-developers] CMake 3.13 - Generated moc files not added to VStudio solution Message-ID: The first CMake generation pass: Generates but no inclusion *Forcing a second pass makes it include the newly generated moc.* It says *"AutoMoc: Generating 'XXXXX' because the MOC settings changed"* I'm not too clear on why this is happening, any ideas on how to fix it, or force it to reload whatever 'moc settings' are changing? Possibly related: https://gitlab.kitware.com/cmake/cmake/issues/17456 e.g. mocs_compilation.cpp and include_XXXX folder -> Created but not added until CMake re-run.... -------------- next part -------------- An HTML attachment was scrubbed... URL: From venytch at gmail.com Tue Jan 29 02:04:10 2019 From: venytch at gmail.com (Venedict Tchistopolskii) Date: Mon, 28 Jan 2019 23:04:10 -0800 Subject: [cmake-developers] CMake 3.13 - Generated moc files not added to VStudio solution In-Reply-To: References: Message-ID: tl;dr, the below does not work for me: The resulting moc_.cpp files are generated in custom directories and automatically included in a generated /mocs_compilation.cpp file, *which is compiled as part of the target. (nope....)* On Mon, Jan 28, 2019 at 10:06 PM Venedict Tchistopolskii wrote: > The first CMake generation pass: Generates but no inclusion > > > > *Forcing a second pass makes it include the newly generated moc.* > It says *"AutoMoc: Generating 'XXXXX' because the MOC settings changed"* > > I'm not too clear on why this is happening, any ideas on how to fix it, or > force it to reload whatever 'moc settings' are changing? > > Possibly related: https://gitlab.kitware.com/cmake/cmake/issues/17456 > > e.g. mocs_compilation.cpp and include_XXXX folder -> Created but not added > until CMake re-run.... > -------------- next part -------------- An HTML attachment was scrubbed... URL: From venytch at gmail.com Tue Jan 29 02:25:33 2019 From: venytch at gmail.com (Venedict Tchistopolskii) Date: Mon, 28 Jan 2019 23:25:33 -0800 Subject: [cmake-developers] CMake 3.13 - Generated moc files not added to VStudio solution In-Reply-To: References: Message-ID: Current automoc settings more or less, it's a solution with a few projects some of which are marked AUTOMOC: ## Relative to root in solution explorer set_property(GLOBAL PROPERTY AUTOGEN_TARGETS_FOLDER "${VS_FOLDER_PREFIX}/Sandbox/AUTOMOC_Targets") ## Relative to each project set_property(GLOBAL PROPERTY AUTOGEN_SOURCE_GROUP "AUTOMOC_Generated") AUTOGEN_TARGETS_FOLDER doesn't get created, but in CMake 3.12 it did the same and worked. AUTOMOC_Generated gets created (per project ofc) and added in CMake 3.12 during the build. For CMake 3.13 it gets created, but not added (not visible in solution explorer) during build, gotta re-run CMake to include it. On Mon, Jan 28, 2019 at 11:04 PM Venedict Tchistopolskii wrote: > tl;dr, the below does not work for me: > > The resulting moc_.cpp files are generated in custom > directories and automatically included in a generated > /mocs_compilation.cpp file, *which is compiled as part > of the target. (nope....)* > > On Mon, Jan 28, 2019 at 10:06 PM Venedict Tchistopolskii < > venytch at gmail.com> wrote: > >> The first CMake generation pass: Generates but no inclusion >> >> >> >> *Forcing a second pass makes it include the newly generated moc.* >> It says *"AutoMoc: Generating 'XXXXX' because the MOC settings changed"* >> >> I'm not too clear on why this is happening, any ideas on how to fix it, >> or force it to reload whatever 'moc settings' are changing? >> >> Possibly related: https://gitlab.kitware.com/cmake/cmake/issues/17456 >> >> e.g. mocs_compilation.cpp and include_XXXX folder -> Created but not >> added until CMake re-run.... >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.wuttke at fz-juelich.de Tue Jan 29 05:37:48 2019 From: j.wuttke at fz-juelich.de (Joachim Wuttke) Date: Tue, 29 Jan 2019 11:37:48 +0100 Subject: [cmake-developers] CMAKE_HOME_DIRECTORY vs CMAKE_SOURCE_DIR Message-ID: how do these two relate to each other? - Joachim -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5110 bytes Desc: S/MIME Cryptographic Signature URL: From brad.king at kitware.com Tue Jan 29 06:49:42 2019 From: brad.king at kitware.com (Brad King) Date: Tue, 29 Jan 2019 06:49:42 -0500 Subject: [cmake-developers] CMAKE_HOME_DIRECTORY vs CMAKE_SOURCE_DIR In-Reply-To: References: Message-ID: <79f7d193-ad9a-c5bb-c0c5-2a289bf82600@kitware.com> On 1/29/19 5:37 AM, Joachim Wuttke wrote: > how do these two relate to each other? Their value is the same, but CMAKE_SOURCE_DIR is a normal CMake variable intended for use by projects. CMAKE_HOME_DIRECTORY is an internal cache entry used to locate the source directory when loading a `CMakeCache.txt` from a build tree. CMAKE_HOME_DIRECTORY's presence in the modern documentation looks historical and accidental. It should either be removed or updated to be described as internal to CMake. Thanks, -Brad From venytch at gmail.com Tue Jan 29 17:38:26 2019 From: venytch at gmail.com (Venedict Tchistopolskii) Date: Tue, 29 Jan 2019 14:38:26 -0800 Subject: [cmake-developers] CMake 3.13 - Generated moc files not added to VStudio solution In-Reply-To: References: Message-ID: *Lots more testing, traced down a possible issue here involving PCH and mocs_compilation.cpp:* get_target_property(HAS_AUTOMOC ${TargetProject} AUTOMOC) if (HAS_AUTOMOC STREQUAL "TRUE") set (MOC_COMPILATION "${CMAKE_CURRENT_BINARY_DIR}/${TargetProject}_autogen/mocs_compilation.cpp") # stdafx.h needs to be included to ensure platform definitions are visible set_property(SOURCE "${MOC_COMPILATION}" APPEND_STRING PROPERTY COMPILE_FLAGS " /FI\"${PrecompiledHeader}\"") endif() *If this is ignored, then mocs_compilation.cpp is visible in solution explorer post generation (no need to build). Build ofc proceeds fine, no unresolved externals/etc.* *Please advise.* *VT* On Mon, Jan 28, 2019 at 11:25 PM Venedict Tchistopolskii wrote: > Current automoc settings more or less, it's a solution with a few projects > some of which are marked AUTOMOC: > ## Relative to root in solution explorer > set_property(GLOBAL PROPERTY AUTOGEN_TARGETS_FOLDER > "${VS_FOLDER_PREFIX}/Sandbox/AUTOMOC_Targets") > ## Relative to each project > set_property(GLOBAL PROPERTY AUTOGEN_SOURCE_GROUP "AUTOMOC_Generated") > > AUTOGEN_TARGETS_FOLDER doesn't get created, but in CMake 3.12 it did the > same and worked. > > AUTOMOC_Generated gets created (per project ofc) and added in CMake 3.12 > during the build. > For CMake 3.13 it gets created, but not added (not visible in solution > explorer) during build, gotta re-run CMake to include it. > > On Mon, Jan 28, 2019 at 11:04 PM Venedict Tchistopolskii < > venytch at gmail.com> wrote: > >> tl;dr, the below does not work for me: >> >> The resulting moc_.cpp files are generated in custom >> directories and automatically included in a generated >> /mocs_compilation.cpp file, *which is compiled as >> part of the target. (nope....)* >> >> On Mon, Jan 28, 2019 at 10:06 PM Venedict Tchistopolskii < >> venytch at gmail.com> wrote: >> >>> The first CMake generation pass: Generates but no inclusion >>> >>> >>> >>> *Forcing a second pass makes it include the newly generated moc.* >>> It says *"AutoMoc: Generating 'XXXXX' because the MOC settings changed"* >>> >>> I'm not too clear on why this is happening, any ideas on how to fix it, >>> or force it to reload whatever 'moc settings' are changing? >>> >>> Possibly related: https://gitlab.kitware.com/cmake/cmake/issues/17456 >>> >>> e.g. mocs_compilation.cpp and include_XXXX folder -> Created but not >>> added until CMake re-run.... >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From venytch at gmail.com Tue Jan 29 19:16:37 2019 From: venytch at gmail.com (Venedict Tchistopolskii) Date: Tue, 29 Jan 2019 16:16:37 -0800 Subject: [cmake-developers] CMake 3.13 - Generated moc files not added to VStudio solution In-Reply-To: References: Message-ID: *The below is done right after the above:* set_property(TARGET ${TargetProject } APPEND PROPERTY AUTOMOC_MOC_OPTIONS -b${PrecompiledHeader}) On Tue, Jan 29, 2019 at 2:38 PM Venedict Tchistopolskii wrote: > *Lots more testing, traced down a possible issue here involving PCH and > mocs_compilation.cpp:* > get_target_property(HAS_AUTOMOC ${TargetProject} AUTOMOC) > if (HAS_AUTOMOC STREQUAL "TRUE") > set (MOC_COMPILATION > "${CMAKE_CURRENT_BINARY_DIR}/${TargetProject}_autogen/mocs_compilation.cpp") > # stdafx.h needs to be included to ensure platform definitions are visible > set_property(SOURCE "${MOC_COMPILATION}" APPEND_STRING PROPERTY > COMPILE_FLAGS " /FI\"${PrecompiledHeader}\"") > endif() > > *If this is ignored, then mocs_compilation.cpp is visible in solution > explorer post generation (no need to build). Build ofc proceeds fine, no > unresolved externals/etc.* > > *Please advise.* > > *VT* > > On Mon, Jan 28, 2019 at 11:25 PM Venedict Tchistopolskii < > venytch at gmail.com> wrote: > >> Current automoc settings more or less, it's a solution with a few >> projects some of which are marked AUTOMOC: >> ## Relative to root in solution explorer >> set_property(GLOBAL PROPERTY AUTOGEN_TARGETS_FOLDER >> "${VS_FOLDER_PREFIX}/Sandbox/AUTOMOC_Targets") >> ## Relative to each project >> set_property(GLOBAL PROPERTY AUTOGEN_SOURCE_GROUP "AUTOMOC_Generated") >> >> AUTOGEN_TARGETS_FOLDER doesn't get created, but in CMake 3.12 it did the >> same and worked. >> >> AUTOMOC_Generated gets created (per project ofc) and added in CMake 3.12 >> during the build. >> For CMake 3.13 it gets created, but not added (not visible in solution >> explorer) during build, gotta re-run CMake to include it. >> >> On Mon, Jan 28, 2019 at 11:04 PM Venedict Tchistopolskii < >> venytch at gmail.com> wrote: >> >>> tl;dr, the below does not work for me: >>> >>> The resulting moc_.cpp files are generated in custom >>> directories and automatically included in a generated >>> /mocs_compilation.cpp file, *which is compiled as >>> part of the target. (nope....)* >>> >>> On Mon, Jan 28, 2019 at 10:06 PM Venedict Tchistopolskii < >>> venytch at gmail.com> wrote: >>> >>>> The first CMake generation pass: Generates but no inclusion >>>> >>>> >>>> >>>> *Forcing a second pass makes it include the newly generated moc.* >>>> It says *"AutoMoc: Generating 'XXXXX' because the MOC settings >>>> changed"* >>>> >>>> I'm not too clear on why this is happening, any ideas on how to fix it, >>>> or force it to reload whatever 'moc settings' are changing? >>>> >>>> Possibly related: https://gitlab.kitware.com/cmake/cmake/issues/17456 >>>> >>>> e.g. mocs_compilation.cpp and include_XXXX folder -> Created but not >>>> added until CMake re-run.... >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From venytch at gmail.com Tue Jan 29 23:00:53 2019 From: venytch at gmail.com (Venedict Tchistopolskii) Date: Tue, 29 Jan 2019 20:00:53 -0800 Subject: [cmake-developers] CMake 3.13 - Generated moc files not added to VStudio solution In-Reply-To: References: Message-ID: Traced it down to this exact commit: *2d6cfe2677 Autogen: Split initializer main method * https://github.com/Kitware/CMake/commit/2d6cfe26770d8062081061f9dbcc4e3e6eaa0091 If I rebase before it then it works as expected >:V Working on a fix..... VT On Tue, Jan 29, 2019 at 4:16 PM Venedict Tchistopolskii wrote: > *The below is done right after the above:* > set_property(TARGET ${TargetProject } APPEND PROPERTY AUTOMOC_MOC_OPTIONS > -b${PrecompiledHeader}) > > > On Tue, Jan 29, 2019 at 2:38 PM Venedict Tchistopolskii > wrote: > >> *Lots more testing, traced down a possible issue here involving PCH and >> mocs_compilation.cpp:* >> get_target_property(HAS_AUTOMOC ${TargetProject} AUTOMOC) >> if (HAS_AUTOMOC STREQUAL "TRUE") >> set (MOC_COMPILATION >> "${CMAKE_CURRENT_BINARY_DIR}/${TargetProject}_autogen/mocs_compilation.cpp") >> # stdafx.h needs to be included to ensure platform definitions are visible >> set_property(SOURCE "${MOC_COMPILATION}" APPEND_STRING PROPERTY >> COMPILE_FLAGS " /FI\"${PrecompiledHeader}\"") >> endif() >> >> *If this is ignored, then mocs_compilation.cpp is visible in solution >> explorer post generation (no need to build). Build ofc proceeds fine, no >> unresolved externals/etc.* >> >> *Please advise.* >> >> *VT* >> >> On Mon, Jan 28, 2019 at 11:25 PM Venedict Tchistopolskii < >> venytch at gmail.com> wrote: >> >>> Current automoc settings more or less, it's a solution with a few >>> projects some of which are marked AUTOMOC: >>> ## Relative to root in solution explorer >>> set_property(GLOBAL PROPERTY AUTOGEN_TARGETS_FOLDER >>> "${VS_FOLDER_PREFIX}/Sandbox/AUTOMOC_Targets") >>> ## Relative to each project >>> set_property(GLOBAL PROPERTY AUTOGEN_SOURCE_GROUP "AUTOMOC_Generated") >>> >>> AUTOGEN_TARGETS_FOLDER doesn't get created, but in CMake 3.12 it did the >>> same and worked. >>> >>> AUTOMOC_Generated gets created (per project ofc) and added in CMake 3.12 >>> during the build. >>> For CMake 3.13 it gets created, but not added (not visible in solution >>> explorer) during build, gotta re-run CMake to include it. >>> >>> On Mon, Jan 28, 2019 at 11:04 PM Venedict Tchistopolskii < >>> venytch at gmail.com> wrote: >>> >>>> tl;dr, the below does not work for me: >>>> >>>> The resulting moc_.cpp files are generated in custom >>>> directories and automatically included in a generated >>>> /mocs_compilation.cpp file, *which is compiled as >>>> part of the target. (nope....)* >>>> >>>> On Mon, Jan 28, 2019 at 10:06 PM Venedict Tchistopolskii < >>>> venytch at gmail.com> wrote: >>>> >>>>> The first CMake generation pass: Generates but no inclusion >>>>> >>>>> >>>>> >>>>> *Forcing a second pass makes it include the newly generated moc.* >>>>> It says *"AutoMoc: Generating 'XXXXX' because the MOC settings >>>>> changed"* >>>>> >>>>> I'm not too clear on why this is happening, any ideas on how to fix >>>>> it, or force it to reload whatever 'moc settings' are changing? >>>>> >>>>> Possibly related: https://gitlab.kitware.com/cmake/cmake/issues/17456 >>>>> >>>>> e.g. mocs_compilation.cpp and include_XXXX folder -> Created but not >>>>> added until CMake re-run.... >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From venytch at gmail.com Wed Jan 30 02:25:19 2019 From: venytch at gmail.com (Venedict Tchistopolskii) Date: Tue, 29 Jan 2019 23:25:19 -0800 Subject: [cmake-developers] CMake 3.13 - Generated moc files not added to VStudio solution In-Reply-To: References: Message-ID: Got the fix, hopefully it can be merged in :) https://github.com/Personwithhat/custom_cmake/commit/d7930c36c6aa7956a806a284aa7e1e430ef6c174 VT On Tue, Jan 29, 2019 at 8:00 PM Venedict Tchistopolskii wrote: > Traced it down to this exact commit: > > *2d6cfe2677 Autogen: Split initializer main method * > https://github.com/Kitware/CMake/commit/2d6cfe26770d8062081061f9dbcc4e3e6eaa0091 > > If I rebase before it then it works as expected >:V > > Working on a fix..... > > VT > > On Tue, Jan 29, 2019 at 4:16 PM Venedict Tchistopolskii > wrote: > >> *The below is done right after the above:* >> set_property(TARGET ${TargetProject } APPEND PROPERTY AUTOMOC_MOC_OPTIONS >> -b${PrecompiledHeader}) >> >> >> On Tue, Jan 29, 2019 at 2:38 PM Venedict Tchistopolskii < >> venytch at gmail.com> wrote: >> >>> *Lots more testing, traced down a possible issue here involving PCH and >>> mocs_compilation.cpp:* >>> get_target_property(HAS_AUTOMOC ${TargetProject} AUTOMOC) >>> if (HAS_AUTOMOC STREQUAL "TRUE") >>> set (MOC_COMPILATION >>> "${CMAKE_CURRENT_BINARY_DIR}/${TargetProject}_autogen/mocs_compilation.cpp") >>> # stdafx.h needs to be included to ensure platform definitions are >>> visible >>> set_property(SOURCE "${MOC_COMPILATION}" APPEND_STRING PROPERTY >>> COMPILE_FLAGS " /FI\"${PrecompiledHeader}\"") >>> endif() >>> >>> *If this is ignored, then mocs_compilation.cpp is visible in solution >>> explorer post generation (no need to build). Build ofc proceeds fine, no >>> unresolved externals/etc.* >>> >>> *Please advise.* >>> >>> *VT* >>> >>> On Mon, Jan 28, 2019 at 11:25 PM Venedict Tchistopolskii < >>> venytch at gmail.com> wrote: >>> >>>> Current automoc settings more or less, it's a solution with a few >>>> projects some of which are marked AUTOMOC: >>>> ## Relative to root in solution explorer >>>> set_property(GLOBAL PROPERTY AUTOGEN_TARGETS_FOLDER >>>> "${VS_FOLDER_PREFIX}/Sandbox/AUTOMOC_Targets") >>>> ## Relative to each project >>>> set_property(GLOBAL PROPERTY AUTOGEN_SOURCE_GROUP "AUTOMOC_Generated") >>>> >>>> AUTOGEN_TARGETS_FOLDER doesn't get created, but in CMake 3.12 it did >>>> the same and worked. >>>> >>>> AUTOMOC_Generated gets created (per project ofc) and added in CMake >>>> 3.12 during the build. >>>> For CMake 3.13 it gets created, but not added (not visible in solution >>>> explorer) during build, gotta re-run CMake to include it. >>>> >>>> On Mon, Jan 28, 2019 at 11:04 PM Venedict Tchistopolskii < >>>> venytch at gmail.com> wrote: >>>> >>>>> tl;dr, the below does not work for me: >>>>> >>>>> The resulting moc_.cpp files are generated in custom >>>>> directories and automatically included in a generated >>>>> /mocs_compilation.cpp file, *which is compiled as >>>>> part of the target. (nope....)* >>>>> >>>>> On Mon, Jan 28, 2019 at 10:06 PM Venedict Tchistopolskii < >>>>> venytch at gmail.com> wrote: >>>>> >>>>>> The first CMake generation pass: Generates but no inclusion >>>>>> >>>>>> >>>>>> >>>>>> *Forcing a second pass makes it include the newly generated moc.* >>>>>> It says *"AutoMoc: Generating 'XXXXX' because the MOC settings >>>>>> changed"* >>>>>> >>>>>> I'm not too clear on why this is happening, any ideas on how to fix >>>>>> it, or force it to reload whatever 'moc settings' are changing? >>>>>> >>>>>> Possibly related: https://gitlab.kitware.com/cmake/cmake/issues/17456 >>>>>> >>>>>> e.g. mocs_compilation.cpp and include_XXXX folder -> Created but not >>>>>> added until CMake re-run.... >>>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From seblist at xwmw.org Wed Jan 30 09:30:59 2019 From: seblist at xwmw.org (Sebastian Holtermann) Date: Wed, 30 Jan 2019 15:30:59 +0100 Subject: [cmake-developers] CMake 3.13 - Generated moc files not added to VStudio solution In-Reply-To: References: Message-ID: <2848824.QTEpRPkYD6@blauwal> Hello Venedict, I took a look at this again, thanks for the additional information. In fact this isn't VS specific. I was able to reproduce the issue using Linux/Makefiles. > Got the fix, hopefully it can be merged in :) > https://github.com/Personwithhat/custom_cmake/commit/d7930c36c6aa7956a806a28 > 4aa7e1e430ef6c174 This change is too intrusive and breaks a lot of other things. > >>> set (MOC_COMPILATION > >>> "${CMAKE_CURRENT_BINARY_DIR}/${TargetProject}_autogen/mocs_compilation.c > >>> pp") # stdafx.h needs to be included to ensure platform definitions are > >>> visible > >>> set_property(SOURCE "${MOC_COMPILATION}" APPEND_STRING PROPERTY > >>> COMPILE_FLAGS " /FI\"${PrecompiledHeader}\"") Setting compiler flags on the mocs_compilation.cpp file is the root cause. I'll investigate this deeper. -Sebastian From venytch at gmail.com Wed Jan 30 10:32:34 2019 From: venytch at gmail.com (Venedict Tchistopolskii) Date: Wed, 30 Jan 2019 07:32:34 -0800 Subject: [cmake-developers] CMake 3.13 - Generated moc files not added to VStudio solution In-Reply-To: <2848824.QTEpRPkYD6@blauwal> References: <2848824.QTEpRPkYD6@blauwal> Message-ID: Gotcha, my project builds atm and it's fairly large, didn't know that it broke anything else. Please let me know when someone fixes it :) VT On Wed, Jan 30, 2019 at 6:31 AM Sebastian Holtermann wrote: > Hello Venedict, > > I took a look at this again, thanks for the additional information. > In fact this isn't VS specific. I was able to reproduce the issue using > Linux/Makefiles. > > > Got the fix, hopefully it can be merged in :) > > > https://github.com/Personwithhat/custom_cmake/commit/d7930c36c6aa7956a806a28 > > 4aa7e1e430ef6c174 > > This change is too intrusive and breaks a lot of other things. > > > >>> set (MOC_COMPILATION > > >>> > "${CMAKE_CURRENT_BINARY_DIR}/${TargetProject}_autogen/mocs_compilation.c > > >>> pp") # stdafx.h needs to be included to ensure platform definitions > are > > >>> visible > > >>> set_property(SOURCE "${MOC_COMPILATION}" APPEND_STRING PROPERTY > > >>> COMPILE_FLAGS " /FI\"${PrecompiledHeader}\"") > > Setting compiler flags on the mocs_compilation.cpp file is the root cause. > I'll investigate this deeper. > > -Sebastian > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From venytch at gmail.com Thu Jan 31 11:53:38 2019 From: venytch at gmail.com (Venedict Tchistopolskii) Date: Thu, 31 Jan 2019 08:53:38 -0800 Subject: [cmake-developers] CMake 3.13 - Generated moc files not added to VStudio solution In-Reply-To: References: <2848824.QTEpRPkYD6@blauwal> Message-ID: Any luck? I can try helping ya trace it if you need it. Hoping to get this solved before the weekend xd On Wed, Jan 30, 2019 at 7:32 AM Venedict Tchistopolskii wrote: > Gotcha, my project builds atm and it's fairly large, didn't know that it > broke anything else. > > Please let me know when someone fixes it :) > > VT > > On Wed, Jan 30, 2019 at 6:31 AM Sebastian Holtermann > wrote: > >> Hello Venedict, >> >> I took a look at this again, thanks for the additional information. >> In fact this isn't VS specific. I was able to reproduce the issue using >> Linux/Makefiles. >> >> > Got the fix, hopefully it can be merged in :) >> > >> https://github.com/Personwithhat/custom_cmake/commit/d7930c36c6aa7956a806a28 >> > 4aa7e1e430ef6c174 >> >> This change is too intrusive and breaks a lot of other things. >> >> > >>> set (MOC_COMPILATION >> > >>> >> "${CMAKE_CURRENT_BINARY_DIR}/${TargetProject}_autogen/mocs_compilation.c >> > >>> pp") # stdafx.h needs to be included to ensure platform definitions >> are >> > >>> visible >> > >>> set_property(SOURCE "${MOC_COMPILATION}" APPEND_STRING PROPERTY >> > >>> COMPILE_FLAGS " /FI\"${PrecompiledHeader}\"") >> >> Setting compiler flags on the mocs_compilation.cpp file is the root cause. >> I'll investigate this deeper. >> >> -Sebastian >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From seblist at xwmw.org Thu Jan 31 12:10:40 2019 From: seblist at xwmw.org (Sebastian Holtermann) Date: Thu, 31 Jan 2019 18:10:40 +0100 Subject: [cmake-developers] CMake 3.13 - Generated moc files not added to VStudio solution In-Reply-To: References: Message-ID: <19608580.mvH87DvX2p@blauwal> > Any luck? I can try helping ya trace it if you need it. > I traced this down to some degree. The problem arises from the handling of file path for GENERATED vs non GENERATED files. When the full path for a file is computed in cmSourceFile and the file doesn't exist (mocs_compilation.cpp doesn't, yet), a path error flag is set. The flag won't be raised when the file has the property GENERATED set, which mocs_compilation.cpp hasn't at that point. A quick solution in your CMakeLists.txt is to mark mocs_compilation.cpp GENERATED first like this ``` set_property(SOURCE "${MOC_COMPILATION}" APPEND_STRING PROPERTY GENERATED "1") set_property(SOURCE "${MOC_COMPILATION}" APPEND_STRING PROPERTY COMPILE_FLAGS " /FI\"${PrecompiledHeader}\"") ``` This works here for a small example project. I'm too busy right now to address this in the CMake sources but I'll try to look at it next week. -Sebastian From venytch at gmail.com Thu Jan 31 13:11:50 2019 From: venytch at gmail.com (Venedict Tchistopolskii) Date: Thu, 31 Jan 2019 10:11:50 -0800 Subject: [cmake-developers] CMake 3.13 - Generated moc files not added to VStudio solution In-Reply-To: <19608580.mvH87DvX2p@blauwal> References: <19608580.mvH87DvX2p@blauwal> Message-ID: Thanks! Worked, glad to have a smaller fix. VT On Thu, Jan 31, 2019 at 9:10 AM Sebastian Holtermann wrote: > > Any luck? I can try helping ya trace it if you need it. > > > > I traced this down to some degree. > The problem arises from the handling of file path for GENERATED vs non > GENERATED files. > When the full path for a file is computed in cmSourceFile and the file > doesn't > exist (mocs_compilation.cpp doesn't, yet), a path error flag is set. > The flag won't be raised when the file has the property GENERATED set, > which > mocs_compilation.cpp hasn't at that point. > > A quick solution in your CMakeLists.txt is to mark mocs_compilation.cpp > GENERATED first like this > > ``` > set_property(SOURCE "${MOC_COMPILATION}" APPEND_STRING PROPERTY GENERATED > "1") > set_property(SOURCE "${MOC_COMPILATION}" APPEND_STRING PROPERTY > COMPILE_FLAGS > " /FI\"${PrecompiledHeader}\"") > ``` > > This works here for a small example project. > > I'm too busy right now to address this in the CMake sources but I'll try > to > look at it next week. > > -Sebastian > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zack.galbreath at kitware.com Thu Jan 31 13:53:48 2019 From: zack.galbreath at kitware.com (Zack Galbreath) Date: Thu, 31 Jan 2019 13:53:48 -0500 Subject: [cmake-developers] CDash frontend refresh Message-ID: We've been working on a refresh of CDash's look and feel. Before rolling this out, we wanted to give you all a sneak peek so that you could let us know what you think. Our proposed changes are now live on http://testing.cdash.org, which shares a backend database with https://open.cdash.org. For example, old: https://open.cdash.org/index.php?project=VTK new: http://testing.cdash.org/index.php?project=VTK This is inevitably a work in progress so future tweaks should be expected. That being said, please let us know if you see anything that seems like an obvious defect to you. -------------- next part -------------- An HTML attachment was scrubbed... URL: