Re: [cmake-developers] Extending XCode scheme generation support
Hi Gregor, I know you are probably busy with other things, but do you see anything in the discussion so far that should prevent an implementation attempt? I don't have a whole lot of time available to work on this either, so progress will probably be slow with me squeezing in work here and there, so I don't think there will be a review burden soon. Thanks, Steven On Sun, Oct 8, 2017 at 1:18 PM, Steven Velez <sbv1...@gmail.com> wrote: > After spending some time trying to figure out how to affect the build > "destination", it seems that destinations associated with a given > scheme are not influenced by anything beyond the targets referenced as > build targets for the scheme. In other words, if a scheme builds an > iOS target, then the iOS destinations/devices/simulators will be > present in the UI, and if it references a MacOS target, then the > active computer will be available in the destinations UI. > > The options available in the scheme proper seem to be similar in > either case, and the proposal so far is fairly agnostic to specific > options, so I think the current proposal stands without modification > in this respect. Does this seem like a reasonable statement? > > This investigation did make me realize that each scheme can specify > building more than one target, so I would revise my statement that the > last target referencing a given scheme name should "win". Instead, I > think each target should be built by the given scheme, and the union > of settings provided by each target should be present in the scheme. > If multiple targets indicate a similar setting, then in this case, the > last setting should win, and this should print a warning... but if > order of processing the schemes/targets cannot match source order, > then perhaps it should be noted that what is "last" cannot be > guaranteed > > Thanks, > Steven > > > On Thu, Oct 5, 2017 at 9:26 AM, Steven Velez <sbv1...@gmail.com> wrote: >> Thanks for the followup Gregor. >> >> One thing that concerns me about the property-centric approach is that >> I can't think of a way to use properties for generating a custom >> scheme that builds the ALL_BUILD target. I would assume this would >> run into the same issues and limitations that I have seen in google >> searches with trying to control the the folder for the ALL_BUILD >> target with the FOLDER target property (even though this would be a >> Visual Studio concern). It seems that is addressed now with the >> *_TARGETS_FOLDER global properties, so maybe an analog can be >> established? >> >> Regarding sequencing changes, do you mean to come up with a set of >> smaller logical changes/MRs so that this isn't all dumped at once? If >> so, I think we could implement XCODE_SCHEME_NAME and a single >> additional property without generator support, then add generator >> support, then add the balance of the properties one-by-one. Would >> that make sense? >> >> I have to get more familiar with CMake's testing methodologies to have >> any comment on that portion. >> >> If two targets specify the same schema name, then overwrite/accept >> latest with a warning? >> >> Regarding ios builds or perhaps having multiple build devices (I have >> seen some hand-made projects with 64-bit and 32-bit desktop clients >> selectable), then I will also have to get back to you on that. I was >> thinking the property definitions were generic enough to handle any >> needs... and I assumed that devices were handles with additional >> scheme files, but I realize that was a bad assumption. >> >> Will try to have that thought out soon. >> >> Thanks, >> Steven >> >> On Mon, Oct 2, 2017 at 9:05 AM, Gregor Jasny <gja...@googlemail.com> wrote: >>> Hello Steven, >>> >>> On 9/22/17 3:36 AM, Steven Velez wrote: >>>> # Property-Centric >>>> In this proposal, the generation of the scheme files is customized >>>> primarily by >>>> a user setting additional, specialized properties on a given target, which >>>> then >>>> affect the generation of the scheme files associated with that target. >>> thank you for working an the scheme proposal. I also believe that the >>> property-centric approach is better suited and easier to implement than >>> the file-centrix one. >>> >>> Next steps would be to sequence the necessary changes and define test >>> cases. I could imagine that adding generator-expression support would be >>> much harder to implement that other things. >>> >>> Things tha
Re: [cmake-developers] Extending XCode scheme generation support
After spending some time trying to figure out how to affect the build "destination", it seems that destinations associated with a given scheme are not influenced by anything beyond the targets referenced as build targets for the scheme. In other words, if a scheme builds an iOS target, then the iOS destinations/devices/simulators will be present in the UI, and if it references a MacOS target, then the active computer will be available in the destinations UI. The options available in the scheme proper seem to be similar in either case, and the proposal so far is fairly agnostic to specific options, so I think the current proposal stands without modification in this respect. Does this seem like a reasonable statement? This investigation did make me realize that each scheme can specify building more than one target, so I would revise my statement that the last target referencing a given scheme name should "win". Instead, I think each target should be built by the given scheme, and the union of settings provided by each target should be present in the scheme. If multiple targets indicate a similar setting, then in this case, the last setting should win, and this should print a warning... but if order of processing the schemes/targets cannot match source order, then perhaps it should be noted that what is "last" cannot be guaranteed Thanks, Steven On Thu, Oct 5, 2017 at 9:26 AM, Steven Velez <sbv1...@gmail.com> wrote: > Thanks for the followup Gregor. > > One thing that concerns me about the property-centric approach is that > I can't think of a way to use properties for generating a custom > scheme that builds the ALL_BUILD target. I would assume this would > run into the same issues and limitations that I have seen in google > searches with trying to control the the folder for the ALL_BUILD > target with the FOLDER target property (even though this would be a > Visual Studio concern). It seems that is addressed now with the > *_TARGETS_FOLDER global properties, so maybe an analog can be > established? > > Regarding sequencing changes, do you mean to come up with a set of > smaller logical changes/MRs so that this isn't all dumped at once? If > so, I think we could implement XCODE_SCHEME_NAME and a single > additional property without generator support, then add generator > support, then add the balance of the properties one-by-one. Would > that make sense? > > I have to get more familiar with CMake's testing methodologies to have > any comment on that portion. > > If two targets specify the same schema name, then overwrite/accept > latest with a warning? > > Regarding ios builds or perhaps having multiple build devices (I have > seen some hand-made projects with 64-bit and 32-bit desktop clients > selectable), then I will also have to get back to you on that. I was > thinking the property definitions were generic enough to handle any > needs... and I assumed that devices were handles with additional > scheme files, but I realize that was a bad assumption. > > Will try to have that thought out soon. > > Thanks, > Steven > > On Mon, Oct 2, 2017 at 9:05 AM, Gregor Jasny <gja...@googlemail.com> wrote: >> Hello Steven, >> >> On 9/22/17 3:36 AM, Steven Velez wrote: >>> # Property-Centric >>> In this proposal, the generation of the scheme files is customized >>> primarily by >>> a user setting additional, specialized properties on a given target, which >>> then >>> affect the generation of the scheme files associated with that target. >> thank you for working an the scheme proposal. I also believe that the >> property-centric approach is better suited and easier to implement than >> the file-centrix one. >> >> Next steps would be to sequence the necessary changes and define test >> cases. I could imagine that adding generator-expression support would be >> much harder to implement that other things. >> >> Things that also should be considered are: >> * differences between macOS and iOS when generating a scheme >> * what should happen if two targets specify the same schema name >> >> Thanks, >> Gregor -- 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Extending XCode scheme generation support
Thanks for the followup Gregor. One thing that concerns me about the property-centric approach is that I can't think of a way to use properties for generating a custom scheme that builds the ALL_BUILD target. I would assume this would run into the same issues and limitations that I have seen in google searches with trying to control the the folder for the ALL_BUILD target with the FOLDER target property (even though this would be a Visual Studio concern). It seems that is addressed now with the *_TARGETS_FOLDER global properties, so maybe an analog can be established? Regarding sequencing changes, do you mean to come up with a set of smaller logical changes/MRs so that this isn't all dumped at once? If so, I think we could implement XCODE_SCHEME_NAME and a single additional property without generator support, then add generator support, then add the balance of the properties one-by-one. Would that make sense? I have to get more familiar with CMake's testing methodologies to have any comment on that portion. If two targets specify the same schema name, then overwrite/accept latest with a warning? Regarding ios builds or perhaps having multiple build devices (I have seen some hand-made projects with 64-bit and 32-bit desktop clients selectable), then I will also have to get back to you on that. I was thinking the property definitions were generic enough to handle any needs... and I assumed that devices were handles with additional scheme files, but I realize that was a bad assumption. Will try to have that thought out soon. Thanks, Steven On Mon, Oct 2, 2017 at 9:05 AM, Gregor Jasny <gja...@googlemail.com> wrote: > Hello Steven, > > On 9/22/17 3:36 AM, Steven Velez wrote: >> # Property-Centric >> In this proposal, the generation of the scheme files is customized primarily >> by >> a user setting additional, specialized properties on a given target, which >> then >> affect the generation of the scheme files associated with that target. > thank you for working an the scheme proposal. I also believe that the > property-centric approach is better suited and easier to implement than > the file-centrix one. > > Next steps would be to sequence the necessary changes and define test > cases. I could imagine that adding generator-expression support would be > much harder to implement that other things. > > Things that also should be considered are: > * differences between macOS and iOS when generating a scheme > * what should happen if two targets specify the same schema name > > Thanks, > Gregor -- 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Extending XCode scheme generation support
Hi guys, Any thoughts on this? TL;DR Version: We can add some target properties that the Xcode generator uses to customize schemes: * XCODE_SCHEME_NAME * XCODE_SCHEME_LAUNCH_OPTS * XCODE_SCHEME_LAUNCH_ADTL_OPTS * XCODE_SCHEME_LAUNCH_RUNNABLE * XCODE_SCHEME_LAUNCH_ARGUMENTS * XCODE_SCHEME_LAUNCH_ENVIRONMENT OR The configure_file function can be augmented to be runnable during generation so that it can process generator expressions which are defined to support this scheme-customization workflow. Thanks, Steven On Thu, Sep 21, 2017 at 9:36 PM, Steven Velez <sbv1...@gmail.com> wrote: > Hello Again, > > Sorry for the delay. After some consideration and investigation, I have the > following two proposals: > > # Property-Centric > In this proposal, the generation of the scheme files is customized primarily > by > a user setting additional, specialized properties on a given target, which > then > affect the generation of the scheme files associated with that target. Scheme > files are persisted as xml, and currently, each scheme file contains six > elements directly underneath the root element which correspond to each of the > [scheme actions](http://help.apple.com/xcode/mac/8.3/#/devd9c8382e7) available > in the scheme editor. > > To this end, with one exception, the specialized properties defined for this > purpose will follow the convention `XCODE_SCHEME__` > where > `` may be one of `BUILD`, `TEST`, `LAUNCH`, `PROFILE`, `ANALYZE`, > `ARCHIVE` and `` will be appropriate to the particular item being > configured and detailed further below. The exception to this convention is > the > `XCODE_SCHEME_NAME` property which will be used to override the default name > of > the generated scheme that by default matches the name of the target it is > associated to. It can even be set to the empty string in order to completely > disable scheme generation for select targets. > > These properties will be ignored by all generators but the Xcode generator. > > ## CONFIGIDs > Being unable to find official, public documentation on the design and format > of > xcode scheme files, experimental analysis has revealed that that there are > approximately three classes of configuration methods used in each action's xml > element. The first class of options are specified as attributes of the > action's > xml element. The second class of options are specified as elements providing > name/value pairs via attributes and are are children of an `AdditionalOptions` > element in the action element, and the final class is everything else and > which > has a different format in each case. > > This proposal is primarily concerned with extending and controlling the > configuration of the Launch action and therefore includes CONFIGIDs that apply > to that action, though it is possible and in some cases likely that they will > have general utility in most other actions. These are as follows: > > * `OPTS` - Properties with this config id will be a CMake list of name/value > pairs where the names and values are strings separated by the first embedded > equals sign. Once parsed, the names will be used to identify xml attributes to > set on the action element and the values will of course be the values set on > those attributes. > * `ADTL_OPTS` - Like with the `OPTS` config id, this will be a list of > name/value pairs. However, the names and values will be used to define xml > elements of the form ` isEnabled="YES"/>` which are then added to the `` element > of the current action. Note, that there are no provisions for controlling the > `isEnabled` state of an option besides those programmatic elements of CMake > which would make it possible to specify (or not) a given additional option. > It is unclear what the semantic difference is between "options" and > "additional options" as there is no clear distinction in the Xcode UI. > * `RUNNABLE` - This is a simple string which can be interpreted as a target > reference if it matches the name of an executable target in the project, or a > literal path to an executable on the file system otherwise. In either case, > it specifies the executable which will be run when the scheme is active. When > no `RUNNABLE` target is specified, the current, default runnable is used. > * `ARGUMENTS` - Is a CMake list of strings that each define an element of the > form `` to add to > the `` element of the current action. As with > `ADTL_OPTS`, `isEnabled` cannot be changed. These values are passed to the > executable specified by `RUNNABLE` as command line arguments. > * `ENVIRONMENT` - This is similar to `ADTL_OPTS` except the elements created > are > of the form ` isEnabled="YES"/>` and they are added to the `` element
Re: [cmake-developers] Extending XCode scheme generation support
guration. The value that
`$` evaluates to for `XCODE_SCHEME_NAME` should persist for every
evaluation of `$` while a given scheme file is being generated. If
`$` is used in a property for which `$` was not also indicated
in `XCODE_SCHEME_NAME`, the results are undefined.
## Examples
Configure xcode to generate a scheme that will aid in debugging a cli program's
help option
```
add_executable(simple_tool simpletool.c)
set_target_properties(simple_tool
XCODE_SCHEME_LAUNCH_ARGUMENTS --help)
```
Configure schemes that build specific shared libraries to execute a common
executable target.
```
add_library(tools1 SHARED tools1.c)
add_library(tools2 SHARED tools2.c)
add_executable(main main.c)
target_link_libraries(main tools1 tools2)
set_target_properties(tools1 tools2
XCODE_SCHEME_NAME "$|$"
XCODE_SCHEME_LAUNCH_OPTS "buildConfiguration=$"
XCODE_SCHEME_LAUNCH_RUNNABLE main)
```
Enable test tooling built in to the app via an environment variable and coax the
linker in to loading the Qt debug libraries
```
add_executable(qtapp qtmain.cpp)
set(_env
"ENABLE_TEST_TOOLBAR=1"
"$<$:DYLD_IMAGE_SUFFIX=_debug>")
set_target_properties(qtapp
XCODE_SCHEME_NAME "qtapp -- $"
XCODE_SCHEME_ENVIRONMENT ${_env})
```
# Scheme-File-centric
While the property-centric proposal described above seems relatively capable,
and it follows conventions established by the `MACOSX_*`, `VS_*`, `XCODE_*`
properties already defined and others, they seem fairly invasive, high
maintenance, and they do not allow schemes targeting built-in projects (such as
ALL_BUILD) to be customized. Further, it seems as though scheme/target
relationships are basically 1:1. Apart from configuration variants, it is not
possible to have more than one scheme reference a given target as a build
dependency, and it is certainly not possible to have the build action of a
scheme build more than a single top-level target.
I believe all of these issues could be addressed and additional leverage given
to users to utilize the full abilities of schemes now and in the future, by
adding two additional CMake features.
The first is to add a flag to `configure_file` that will cause it to run during
the generation phase and therefore be able to expand generator expressions.
The second is to define an xcode-specific read-only target property:
`XCODE_BLUEPRINT_ID`.
Once these constructs are available, a user could configure files with bits of
xml that look like this:
```xml
```
I believe that the fact that the blue print id for a given target changes on
each generation, is the only thing preventing scheme files from being manually
(and flexibly) created during the configure phase.
In full disclaimer: I have not investigated the feasibility of implementing such
a solution
Thanks,
Steven
On Fri, Sep 15, 2017 at 11:48 AM, Steven Velez <sbv1...@gmail.com> wrote:
> Sure.. but I haven't even thought about it much yet. So when that has
> happened, I'll make a more formal proposal.
>
> Thanks,
> Steven
>
> On Fri, Sep 15, 2017 at 11:04 AM, Brad King <brad.k...@kitware.com> wrote:
>>
>> On 09/15/2017 10:55 AM, Steven Velez wrote:
>> > I am assuming that the lack of response indicates that there has not
>> > been much thought or interest expressed along this dimension of the
>> > feature.
>> >
>> > Would a better way to approach this be to implement a prototype and
>> > create a WIP MR?
>>
>> Can you post a more specific proposal here? E.g. with proposed
>> target properties to control it and show some examples.
>>
>> Thanks,
>> -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:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] setting/removing compiler flag (-g) for a single project directory
Gotcha... yeah target definitions are available globally, in all directories after they are defined (source order is important). I had never thought of this as a global variable or constant, but I guess in a way it is. In that way, then I would think it is a sort of special case... but I suppose the experts should chime in. Steven On Sat, Sep 16, 2017 at 4:07 AM, René J.V. Bertin <rjvber...@gmail.com> wrote: > On Friday September 15 2017 16:51:24 Steven Velez wrote: > > >Yeah... I didn't mean to respond personally... i didn't realize my client > >was doing that and not the list. > > OK, replying back to the list then. > > >What do you mean by "variables related to targets have global scope"? > > I probably could have been a bit less vague. Defining a target in a > subdirectory sets something that behaves like a global variable (pardon, > constant :)), at least for libraries. That's the whole point of that > common_dir subtree: it defines library targets which are then used for > linking the plugin. > > R. > > > > >On Fri, Sep 15, 2017 at 3:44 PM, René J.V. Bertin <rjvber...@gmail.com> > >wrote: > > > >> On Friday September 15 2017 15:34:34 Steven Velez wrote: > >> > >> Logically that's what I'd expect, but then the variables related to > >> targets have global scope, variables set in a module directories too > etc. I > >> preferred to ask, so thanks :) > >> > >> R. > >> > >> >All directories in cmake have their own scopes which are initialized by > >> the > >> >scope of the parent directory. > >> > > >> >So, if you set the variables you wish to set in CMakeLists.txt of > >> >common_libs, they should not influence the builds in the plugin > directory, > >> >but will influence the builds in that directory and subdirectories. > >> > > >> >https://cmake.org/cmake/help/v3.9/manual/cmake-language.7. > >> html#cmake-language-variables > >> > > >> >For more info. > >> > > >> >Steven > > -- > > 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: > http://public.kitware.com/mailman/listinfo/cmake > -- 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: http://public.kitware.com/mailman/listinfo/cmake
Re: [cmake-developers] Extending XCode scheme generation support
Sure.. but I haven't even thought about it much yet. So when that has happened, I'll make a more formal proposal. Thanks, Steven On Fri, Sep 15, 2017 at 11:04 AM, Brad King <brad.k...@kitware.com> wrote: > On 09/15/2017 10:55 AM, Steven Velez wrote: > > I am assuming that the lack of response indicates that there has not > > been much thought or interest expressed along this dimension of the > feature. > > > > Would a better way to approach this be to implement a prototype and > create a WIP MR? > > Can you post a more specific proposal here? E.g. with proposed > target properties to control it and show some examples. > > Thanks, > -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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Extending XCode scheme generation support
Hello, I am assuming that the lack of response indicates that there has not been much thought or interest expressed along this dimension of the feature. Would a better way to approach this be to implement a prototype and create a WIP MR? Thanks, Steven On Fri, Sep 8, 2017 at 12:29 PM, Steven Velez <sbv1...@gmail.com> wrote: > Hello All, > > I recently noticed that 3.9.1 added the ability for the XCode generator to > also generate scheme files. This is great as we have been post processing > generator output to add schemes according to our standards, but are > discovering various issues with this approach. > > However, the current scheme generation appears to lack a couple of > abilities we would require to replace our custom scripts. Primarily, we > need more flexibility over what goes in a particular scheme's launch > configuration. > > I have searched the lists and google to try to find discussions on the > intended direction of this feature, but could not find any. > > If I were to be able to contribute to this, would there be some sort of > guidance available around how best to expose additional configurability to > a user? My immediate thoughts are just that we would need to define/use > additional target properties, but is there any sort of recommended naming > convention/scheme or structure that is already existing for mapping sets of > properties in to the more structured format of scheme xml files. > > Thanks, > Steven > -- 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: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Extending XCode scheme generation support
Hello All, I recently noticed that 3.9.1 added the ability for the XCode generator to also generate scheme files. This is great as we have been post processing generator output to add schemes according to our standards, but are discovering various issues with this approach. However, the current scheme generation appears to lack a couple of abilities we would require to replace our custom scripts. Primarily, we need more flexibility over what goes in a particular scheme's launch configuration. I have searched the lists and google to try to find discussions on the intended direction of this feature, but could not find any. If I were to be able to contribute to this, would there be some sort of guidance available around how best to expose additional configurability to a user? My immediate thoughts are just that we would need to define/use additional target properties, but is there any sort of recommended naming convention/scheme or structure that is already existing for mapping sets of properties in to the more structured format of scheme xml files. Thanks, Steven -- 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: http://public.kitware.com/mailman/listinfo/cmake-developers
[CMake] ZERO_CHECK generation and Xcode
If I understand correctly the purpose of the ZERO_CHECK target is to update the generated project files when necessary. That's fine, but I have noticed on Xcode (8.2) that when ZERO_CHECK runs and updates the project, it causes the xcode build to abort. Unfortunately, it seems this build abort happens before the xcode project regeneration has a chance to complete and update/touch CMakeFiles/cmake.check_cache, so once the target is out of date, it pretty much stays that way, and the builds are always (or least frequently) subsequently aborted because of an update to generated project files. If I go in to the terminal and manually execute "make -f ReRunCMake.make" then the process completes and the ZERO_CHECK target is good, and it does not run any more. Is there any known way to deal with this other than by specifying CMAKE_SUPRRESS_REGENERATION:BOOL=YES ? Thanks, Steven -- 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: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] What is the purpose of cmake's -N parameter?
Well, sent that a little too soon. I just realized that in my testing, I wasn't specifying the source directory (which is an error) and when I do "-N" does affect how "-L" behaves... However, -L still leaves a lot of cache variables out (as does -LA), and I would like to see the value of CMAKE_PROJECT_NAME. Any tips? Thanks, Steven On Thu, May 19, 2016 at 2:16 PM, Steven Velez <sbv1...@gmail.com> wrote: > The docs say: > > View mode only. >> >> Only load the cache. Do not actually run configure and generate steps. >> > > But I wonder what you can do with cmake after that to view the cache? > > The -L parameter seems to display the same set of variables with or > without this set, and scripts run in process script mode still seem to have > no access to cache values. > > So, what's left? > > To state my problem a little more generally I would like a way to discover > the project name set in a binary dir by it's associated CMakeLists.txt file. > > Is this possible without writing my own code to parse either the > CMakeLists.txt or CMakeCache.txt? > > Thanks, > Steven > -- 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: http://public.kitware.com/mailman/listinfo/cmake
[CMake] What is the purpose of cmake's -N parameter?
The docs say: View mode only. > > Only load the cache. Do not actually run configure and generate steps. > But I wonder what you can do with cmake after that to view the cache? The -L parameter seems to display the same set of variables with or without this set, and scripts run in process script mode still seem to have no access to cache values. So, what's left? To state my problem a little more generally I would like a way to discover the project name set in a binary dir by it's associated CMakeLists.txt file. Is this possible without writing my own code to parse either the CMakeLists.txt or CMakeCache.txt? Thanks, Steven -- 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: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] VERSION and SOVERSION target properties on OS X
Ah... good idea. I should have considered that. Thanks. On Mon, Oct 13, 2014 at 11:50 AM, Clinton Stimpson clin...@elemtech.com wrote: On Friday, October 10, 2014 12:43:53 PM Steven Velez wrote: Forgive me if this question has been answered before but with CMAKE 2.8.12 (I believe) xcode builds on OS X started generating shared libraries decorated with the VERSION target property and symlinked by a bare dylib name and one decorated with the SOVERSION. I understand this is common practice on many unixen, but it is complicating our deployment and update logic (not cpack, sorry to say). Our application is fairly self-contained, so we would like to continue generating only those bare-named dylibs, but we need to keep the SOVERSION set to that the embedded compatibility version remains how we want it. I have not found a combination of values to these properties that does what I would like, so I was wondering if there was a way to get the old behavior perhaps with a policy or something? If there isn't a way to do it now, would there be an acceptable way to specify this behavior that would be accepted as a patch? Thanks, Steven That change was made to make the Xcode and Makefile generators consistent. To get what you want now (with both the older and newer CMake versions), you can remove the SOVERSION property and set the LINK_FLAGS property to pass - compatibilty_version to the linker. Clint -- 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: http://public.kitware.com/mailman/listinfo/cmake
[CMake] VERSION and SOVERSION target properties on OS X
Forgive me if this question has been answered before but with CMAKE 2.8.12 (I believe) xcode builds on OS X started generating shared libraries decorated with the VERSION target property and symlinked by a bare dylib name and one decorated with the SOVERSION. I understand this is common practice on many unixen, but it is complicating our deployment and update logic (not cpack, sorry to say). Our application is fairly self-contained, so we would like to continue generating only those bare-named dylibs, but we need to keep the SOVERSION set to that the embedded compatibility version remains how we want it. I have not found a combination of values to these properties that does what I would like, so I was wondering if there was a way to get the old behavior perhaps with a policy or something? If there isn't a way to do it now, would there be an acceptable way to specify this behavior that would be accepted as a patch? Thanks, Steven -- 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: http://public.kitware.com/mailman/listinfo/cmake
[CMake] Properties on Projects ( was: Enhancing the Visual Studio Generators' Source Control integration )
Trying again more directly. Sorry for the chattiness. Is there a good way to allow users to set properties on projects that generators can read. I was thinking to use standardized global properties e.g.) Project Name_VS_SCC_LOCALPATH, however the existing properties like this ( projectname_SOURCE_DIR and projectname_BINARY_DIR ) are implicitly read-only. Would there be a reason to avoid my proposal? Thanks, Steven On Tue, Nov 1, 2011 at 12:34 AM, Steven Velez sbv1...@gmail.com wrote: Hi All, We have noticed, that using the VS_SCC_* target properties, we can bind to a perforce SCM server. However, the way that SCC works the perforce plugin has to prompt the user for connection information. When we were doing this with hand-made visual studio solutions, we would only be prompted once when the workspace was fresh and clean, and the information would be retained thereafter. With our CMake-generated solutions, we are prompted on every invocation of visual studio. We'd like to get back to the fewer prompts workflow. After much research and trial and error, we have discovered that this seems to be because the bindings created by cmake are stored in the visual studio project files...and only there. It seems that a more complete binding also records some SCC-related properties in the solution file... Therefore, I started hacking on the visual studio generator to try and decipher how this functionality would be added to cmake, and made good progress. However, there are some solution file properties related to SCC that must be recorded for the solution itself. For most entries, I can just query the targets' VS_SCC_ properties, but there are no such properties for the solution/project. What's more, is there is no existing precedent, that I can find, for user-specified project properties. So I am not sure how I would be able to give the user control over what these properties may be. In my scenario, with the perforce SCC plugin, I _could_ get the necessary properties form the first target, but I doubt this is the general solution otherwise there is simply too much redundancy in the protocol/format. Long question short... is there an existing, reliable way for the user to provide per-project properties that the generator can get at? Thanks, Steven -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How the heck does one set options?
Just a guess, but the docs for option state: option(option_variable help string describing option [initial value]) Provide an option for the user to select as ON or OFF. If no initial value is provided, OFF is used. In this description is not optional, but the initial value is. In the usage presented, I believe ON may be interpreted as the doc string and the default value is being taken? Maybe Tim made a mistake in his reply. I don't know personally, I've never used this. Steven On Wed, Nov 2, 2011 at 9:36 PM, Dan Kegel d...@kegel.com wrote: On Wed, Nov 2, 2011 at 6:21 PM, Tim Gallagher tim.gallag...@gatech.edu wrote: Using set() as you have done only sets the value in the current scoping unit. If you did: set(gtest_force_shared_crt ON CACHE INTERNAL ) then it will be set to ON and hidden from the GUI display. If it will always be a bool and you want it displayed on the GUI, you can also do: option(gtest_force_shared_crt ON) Tried it, no change, still broken. $ grep gtest_force_shared_crt CMakeLists.txt build/CMakeCache.txt CMakeLists.txt:option(gtest_force_shared_crt ON) build/CMakeCache.txt:gtest_force_shared_crt:BOOL=OFF --trace shows CMakeLists.txt(23): option(gtest_force_shared_crt ON ) gtest/CMakeLists.txt(14): option(gtest_force_shared_crt Use shared (DLL) run-time lib even when Google Test is built as static lib. OFF ) So, now what? How does one set an option declared by a subdirectory before entering that subdirectory? Lots of people use gtest, surely someone has run into this before. - Dan -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] SCC bindings missing AUXPATH support?
Just to be clear, I am not advocating having to deal with the perforce SCC integration dialog for every project in the solution. In our set up, we need to deal with it once for the solution... without having access to AuxPath. However, I do imagine, that it probably has something to do with where the local path ends up pointing to and whether your solution pulls projects from different P4 work-spaces, though I have never done that myself personally. I suggested making AuxPath optional because the binding will work without that property, and it will work efficiently if carefully crafted. I can not say that a binding will succeed if any of the other properties are omitted, though perhaps they might with some SCC providers... I didn't write the original binding logic, I don't use other providers, and I certainly have never seen any documentation on the Visual Studio SCC interface... I've heard you need to sign an NDA with Microsoft for that or something. As far as there being logic to using a relative path as opposed to an absolute one, no... I can't say that I know what it is if there is any. Again, I don't fully understand how SCC integration works. I can only say that I have tried relative paths, and they work better for me than the report you provided originally. Also, if I set up the bindings after solution generation from within visual studio 2010, that is what the IDE and/or perforce puts there. Steven On Tue, Nov 1, 2011 at 7:40 AM, Robert Dailey rcdai...@gmail.com wrote: On Mon, Oct 31, 2011 at 11:59 PM, Steven Velez sbv1...@gmail.com wrote: Hi Robert, I reviewed the patch, and I am not sure vsAuxPath should be a requirement. As I stated earlier, we've gotten the binding to work acceptably without it and I assume others have as well. Further, some users may prefer to enter their connection information in to the perforce dialog on first invocation instead of having to configure the cmake cache to setup their bindings. I never said it wouldn't work without AuxPath, I am just stating that it works better with it. AuxPath is where the connection string is placed. Each person that uses CMake is different and I see no reason why AuxPath should not be an available option to the user, especially since I've already done the work of adding it in. If users want to continuously press OK on the perforce connection dialog for every project opened in the solution, that's fine by me but I certainly don't want to deal with that annoying behavior. To be clear, I have no objections to adding AuxPath support (not that my objections count for anything around here). Its that just as it stands now, if you don't supply it, you won't get any bindings. I can easily make it optional. I was just following the design already in place, which forces all parameters to be required. Also, you may have better results getting your patch integrated by opening a defect in cmake's bug tracker and attaching the patch to that. The preferred patch generation method is also described here: http://www.mail-archive.com/cmake@cmake.org/msg36619.html Thanks for the info!! By the way, as I stated in an earlier mail, if you wish to pursue this further, if you change C:/Code/work/sandbox to ..\..\.. where that path points to C:\Code\work\sandbox relative to the target being bound, you should have better results. I read your last email but I fail to see the logic behind why a relative path works better than an absolute one. Based on my tests, using an absolute path has not resulted in any prompts to save the solution/projects. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Source control bindings feature in CMake needs better documentation
Hi Robert,
I don't pretend to know everything there is to know about Visual
Studio SCC integration, but I have gotten this to work before with a
bit of trial and error, and reverse-engineering the entries visual
studio creates for these properties.
To answer your most recent question, there is no way to specify
perforce connection/user/workspace information in the cmake file as
these properties are just forwarded to the generated .vcproj files,
and there is no way to set the parameters you are looking for there.
In your examples, [I have found that] the values you have for project
name and provider are correct when hooking up to perforce. However, I
think you are a bit off the mark on the first parameter to
set_target_properties. This is supposed to be the name of the
_target_ you are binding to scc (the result of a add_executable,
add_library command etc.) not the project name. In the cmake-VS
mapping, a cmake target is a VS project, and a cmake project is a VS
solution (so if you have a project command for every target, you can
most likely start simplifying things there). I mention this because it
may have something to do with the excessive prompting you are
getting... though reviewing my team's integration shows that we are
doing this same thing. Another thing you might want to adjust is the
local path I have had the most success with passing a path
relative to the target's binary directory using the target path format
(in this case, always windows... i.e. use back slashes. To compute
this dynamically, you may have success using file(RELATIVE_PATH) with
CMAKE_CURRENT_BINARY_DIR, and CMAKE_SOURCE_DIR. In VS2010, at least,
we have found that in order to avoid being prompted to save on exit,
we must strip trailing slashes from the path we build in this way.
Following this pattern, we have gotten to the point where we are
prompted once for port and workspace/clientspec on each invocation of
visual studio, but it is only once and not once per project in the
solution.
Steven
On Mon, Oct 31, 2011 at 2:36 PM, Robert Dailey rcdai...@gmail.com wrote:
While waiting on a response I did some experimentation:
set_target_properties(
${project_name} PROPERTIES
VS_SCC_LOCALPATH ${CMAKE_SOURCE_DIR}
VS_SCC_PROJECTNAME Perforce Project
VS_SCC_PROVIDER MSSCCI:Perforce SCM
)
This seems to work in VS 2003 but the annoying thing is that when I open the
solution, every single project (about 120 of them) each prompt me for my
username, workspace, and server URL to perforce server.
Is there no way to specify this connection/user/workspace information in
CMake so that when I open the solution it already knows this stuff?
-
Robert Dailey
On Mon, Oct 31, 2011 at 12:24 PM, Robert Dailey rcdai...@gmail.com wrote:
Hey guys,
Our team is running Perforce here at work and I want to setup any Visual
Studio projects generated to use source control bindings for Perforce.
The documentation for VS_SCC_PROJECTNAME, VS_SCC_LOCALPATH,
VS_SCC_PROVIDER is pretty bad and I really have no clue on how to use these.
Could someone explain what each is and possibly provide some examples on how
they are used for Perforce?
Thanks!!
-
Robert Dailey
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Enhancing the Visual Studio Generators' Source Control integration
Hi All, We have noticed, that using the VS_SCC_* target properties, we can bind to a perforce SCM server. However, the way that SCC works the perforce plugin has to prompt the user for connection information. When we were doing this with hand-made visual studio solutions, we would only be prompted once when the workspace was fresh and clean, and the information would be retained thereafter. With our CMake-generated solutions, we are prompted on every invocation of visual studio. We'd like to get back to the fewer prompts workflow. After much research and trial and error, we have discovered that this seems to be because the bindings created by cmake are stored in the visual studio project files...and only there. It seems that a more complete binding also records some SCC-related properties in the solution file... Therefore, I started hacking on the visual studio generator to try and decipher how this functionality would be added to cmake, and made good progress. However, there are some solution file properties related to SCC that must be recorded for the solution itself. For most entries, I can just query the targets' VS_SCC_ properties, but there are no such properties for the solution/project. What's more, is there is no existing precedent, that I can find, for user-specified project properties. So I am not sure how I would be able to give the user control over what these properties may be. In my scenario, with the perforce SCC plugin, I _could_ get the necessary properties form the first target, but I doubt this is the general solution otherwise there is simply too much redundancy in the protocol/format. Long question short... is there an existing, reliable way for the user to provide per-project properties that the generator can get at? Thanks, Steven -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] SCC bindings missing AUXPATH support?
Hi Robert,
I reviewed the patch, and I am not sure vsAuxPath should be a
requirement. As I stated earlier, we've gotten the binding to work
acceptably without it and I assume others have as well. Further, some
users may prefer to enter their connection information in to the
perforce dialog on first invocation instead of having to configure the
cmake cache to setup their bindings.
To be clear, I have no objections to adding AuxPath support (not that
my objections count for anything around here). Its that just as it
stands now, if you don't supply it, you won't get any bindings.
Also, you may have better results getting your patch integrated by
opening a defect in cmake's bug tracker and attaching the patch to
that. The preferred patch generation method is also described here:
http://www.mail-archive.com/cmake@cmake.org/msg36619.html
By the way, as I stated in an earlier mail, if you wish to pursue this
further, if you change C:/Code/work/sandbox to ..\..\.. where that
path points to C:\Code\work\sandbox relative to the target being
bound, you should have better results.
Thanks,
Steven
On Mon, Oct 31, 2011 at 8:20 PM, Robert Dailey rcdai...@gmail.com wrote:
I forgot to explain why I made the change to begin with. Basically this all
comes down to Perforce binding support. SccAuxPath is used to specify the
Perforce connection string. Without this, each project opened will prompt
the user for the information via modal dialog. This gets very annoying...
Here is an example of how I have setup each of my projects:
set_target_properties(
${project_name} PROPERTIES
VS_SCC_AUXPATH
P4SCC#${PERFORCE_SERVER}##${PERFORCE_USER}##${PERFORCE_WORKSPACE}
VS_SCC_LOCALPATH ${CMAKE_SOURCE_DIR}
VS_SCC_PROJECTNAME Perforce Project
VS_SCC_PROVIDER MSSCCI:Perforce SCM
)
All of the PERFORCE_ variables are cache variables, so that the user can
specify their credentials, server, and workspace. These are all formatted
into the connection string perforce expects.
The resulting XML in the VCPROJ looks like so:
SccProjectName=Perforce Project
SccLocalPath=C:/Code/work/sandbox
SccAuxPath=P4SCC#perforce.mycompany.com:3666##rdailey##rdailey-t510-sandbox
SccProvider=MSSCCI:Perforce SCM
When I open the generated solution, all projects load perfectly with no
prompts and everything is binded to source control :)
-
Robert Dailey
On Mon, Oct 31, 2011 at 7:06 PM, Robert Dailey rcdai...@gmail.com wrote:
I fiddled around with TortoiseGit and managed to create the patch. It is
attached.
Please integrate this into your repository so it is included in version
2.8.7 :)
-
Robert Dailey
On Mon, Oct 31, 2011 at 5:41 PM, Robert Dailey rcdai...@gmail.com wrote:
I have added source code support for this myself. I updated the following
files:
cmLocalVisualStudio7Generator.cxx
cmLocalVisualStudio10TargetGenerator.cxx
The existing SCC support code was already in these files, I just added
the SccAuxPath support to it.
I'm not an expert at creating patch files outside of TortoiseSVN on
Windows, so could someone explain how to create a patch file for these on
Windows 7? Also how would you like me to deliver the code? I hope to see it
introduced in version 2.8.7
Thanks.
-
Robert Dailey
On Mon, Oct 31, 2011 at 4:10 PM, Robert Dailey rcdai...@gmail.com
wrote:
There are actually 4 SCC related key/value pairs used in VS2003 VCPROJ
files:
SccProjectName=SAK
SccAuxPath=SAK
SccLocalPath=SAK
SccProvider=SAK
CMake supports these 3 via set_target_properties():
VS_SCC_LOCALPATH
VS_SCC_PROJECTNAME
VS_SCC_PROVIDER
Apparently one more is needed to support SccAuxPath:
VS_SCC_AUXPATH
Can someone add support for this? Thanks.
-
Robert Dailey
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Announcement: Visual Studio extension for editing CMake files available.
Hello All, This is a one time message to publicize the availability of a project of my own creation that will add CMake language-specific features to visual studio. The project home page is hosted on google code: http://code.google.com/p/vissemee/ I have just made the first binary build available, so I welcome all CMakers who prefer to spend most of their time in Visual Studio (2010 and above only... sorry) to try it out and let me know how it works out for them. As I said before, this is a one time announcement, and if there are any follow-ups or issues, please do not clutter the cmake list. A google group has been establish, and you can sign up for membership there for further discussion. https://groups.google.com/forum/?hl=en#!forum/vissemee-discussion It's been empty for months, so it would be nice to get SOME traffic :) Thanks, Steven -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bug fix requests for the *next* release of CMake...
http://public.kitware.com/Bug/view.php?id=12299 ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building a MS COM Dll with Cmake
Since no one has yet replied, I will comment that this workflow is much like what Qt does with the moc (meta-object-compiler) and uic tools. Looking at the FindQt4.cmake and the referenced Qt4Macros.cmake files, it seems like these could provide some examples to follow... ... though its true they are not structured for instruction. Steven On Thu, Jun 30, 2011 at 5:17 AM, Gerhard Gappmeier gerhard.gappme...@ascolab.com wrote: Hi I'm working on a project which is completely portable, except of one COM wrapper Dll which should be built only on windows. To be consistent with the other parts I also want to build this COM Dll using CMake like I do we the rest of the project. However I don't know how to do this MS magic with CMake. 1.) How do I add a MIDL buildstep? VS normally creates a Typelibrary (TLB) from the IDL file and links this as resource into the DLL. This is necesarry later on for Dll registration. 2.) Also the foo_i.c and foo.h files are generated from foo.idl by the midl compiler which must be compiled with the project. 3.) There are additional rgs-files (registry resources) to add. How do I do that? 4.) Also the version info must be compiled into the dll. Based on a .rc file which includes all vendor info. So set_target_properties VERSION would not be sufficient. It would be great if somebody has an example for a simple COM Dll project. I hope this is possible. -- mit freundlichen Grüßen / best regards Gerhard Gappmeier ascolab GmbH - automation systems communication laboratory Tel.: +49 9131 691 123 Fax: +49 9131 691 128 Web: http://www.ascolab.com GPG-KeyId: 5AAC50C4 GPG-Fingerprint: 967A 15F1 2788 164D CCA3 6C46 07CD 6F82 5AAC 50C4 -- ascolab GmbH Geschäftsführer: Gerhard Gappmeier, Matthias Damm, Uwe Steinkrauß Sitz der Gesellschaft: Am Weichselgarten 7 • 91058 Erlangen • Germany Registernummer: HRB 9360 Registergericht: Amtsgericht Fürth ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Please help with procedure for making contributions
Thanks for the follow-up. We are aware that the idea is to copy and freely distribute the code and all contributions. I think the idea is that IF we are required to sign an agreement, then it doesn't impose any odd, additional requirements/request of us. I think our legal department also mentioned something about being clear on the intentions of expectations of other contributors when we are USING the software, but I believe this is secondary in the contribution case. Thanks, and hopefully I will actually be able to submit the patch soon. Steven On Thu, Jun 16, 2011 at 7:36 AM, David Cole david.c...@kitware.com wrote: On Wed, Jun 15, 2011 at 8:48 PM, Steven Velez sbv1...@gmail.com wrote: Hi All, After having searched the cmake web site and wiki, I have been unable to find a documented procedure for submitting patches to CMake. Via brwosing the bug tracker and watching this list, it seems generally apparent that a non-committer who wants to make a contribution simply opens an issue and attaches his (or her) patch. Is that all there is to it? Yes, that's it. This list and its traffic are the living documentation of CMake, if you will. While we do have the official help documentation web pages, and there is some good stuff on the Wiki, asking here is the way to get answers when searching teh Interwebz yields nothing. To contribute a patch, please search the bug database for an existing issue (or open a new one if necessary), and attach it there. To preserve your authorship in the patch, prepare a git commit with the correct authorship in it, and then use the git command: git format-patch -1 I imagine that like most developers working for an organization focusing on closed source software, everything I produce is legally theirs, so I have been very careful about getting permission from them to make a contribution. However, they would like me to be completely sure of all formalities that must be followed in doing so. For example, do you have contributors sign an assignment of copyright or some other contributor's agreement? Are there any cases in which contributions will not be covered by the same BSD license that CMake is covered by. (be aware, that my patch is very small, and we are just crossing t's). Any information would be appreciated. We do not have an official contributor's agreement that needs to be signed. But if your patch just blends stuff into the existing code base (crossing t's or dotting i's), then it becomes part of the existing code base, covered by the same license CMake is covered by. I am not a lawyer, but the intent of contributing code to an open source project is to allow that project to copy it around and freely distribute it. So if you want to keep any kind of copyright for yourself (or your company), do not contribute it unless you're willing to allow the project to do that even though you retain your own copyright. (You'll notice some of the module files have additional copyrights on top of the standard CMake copyright notice.) Thanks, Steven You're welcome, David ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Please help with procedure for making contributions
Hi All, After having searched the cmake web site and wiki, I have been unable to find a documented procedure for submitting patches to CMake. Via brwosing the bug tracker and watching this list, it seems generally apparent that a non-committer who wants to make a contribution simply opens an issue and attaches his (or her) patch. Is that all there is to it? I imagine that like most developers working for an organization focusing on closed source software, everything I produce is legally theirs, so I have been very careful about getting permission from them to make a contribution. However, they would like me to be completely sure of all formalities that must be followed in doing so. For example, do you have contributors sign an assignment of copyright or some other contributor's agreement? Are there any cases in which contributions will not be covered by the same BSD license that CMake is covered by. (be aware, that my patch is very small, and we are just crossing t's). Any information would be appreciated. Thanks, Steven ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch for watcom InstallRequiredSystemLibraries
I'd like to know the same. Particularly with respect to whether any documents will need to be signed, and for how much longer patches (that aren't bug fixes) will be accepted to 2.8.5. Thanks, Steven On Sat, Jun 4, 2011 at 1:53 AM, J Decker d3c...@gmail.com wrote: so what is the proper way for someone without repository write access to get patches added? On Tue, Feb 15, 2011 at 3:27 PM, J Decker d3c...@gmail.com wrote: http://public.kitware.com/Bug/view.php?id=11866 ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
