Ruslo, I think we all could argue both against and for implementing cmake-ini files inside the cmake command. I mean I'm also aware of all the pros and cons. It's just that we weigh differently. I like loosely connected simpler building blocks and my own cmake-wrapping extension script works fine, that's why I thought you would not lose anything with that.
>> git commit --author="John Doe" --email="john....@example.com" <john....@example.com> --branch="master" >> git push --remote="git://awesome.example.com" > This is a complete nonsense! I agree and that's why I think cmake ini files is a good idea. Tamas On Tue, Mar 15, 2016 at 3:25 AM, Ruslan Baratov <ruslan_bara...@yahoo.com> wrote: > On 15-Mar-16 02:42, Tamás Kenéz wrote: > > I also doubt this belongs to upstream. But you could write a single, > generic script which forwards its arguments to cmake and also accepts and > processes the additional parameters along the way. I don't think we'd lose > anything: > > cmakeini -c ipad -H. -DTHIS_WILL_BE_FORWARDED=AS_IT_IS > > This is the approach I took as I needed features like you described. But > if there would be a mature, versatile, community-tested script I'd be > willing to use it and contribute to it. > > As you can see I'm already using script `build.py` and there is not enough > power for now (even if it extends CMake basic functionality a lot) so I was > thinking to introduce global/local ini-configuration file anyway. Then I > realize that most of the `build.py` functions can be implemented in such > ini-configuration. So why not use CMake? Why for example not extend CMake > GUI with this feature support? Why do users need to install some extra > tools instead of just one? > > Global/local configuration files in not something special. Git for example > has same system, yes it increase complexity but literally every user store > setting there. > Just imagine you have to write something like this every commit + push: > > > git commit --author="John Doe" --email="john....@example.com" > <john....@example.com> --branch="master" > > git push --remote="git://awesome.example.com" > > This is a complete nonsense! > > So I'm planning to make a fork anyway and do some experiments even if it > will not accepted to upstream. > > Ruslo > > > Tamas > > On Mon, Mar 14, 2016 at 4:22 PM, Ruslan Baratov via cmake-developers < > <cmake-developers@cmake.org>cmake-developers@cmake.org> wrote: > >> On 14-Mar-16 21:59, Brad King wrote: >> >>> On 03/12/2016 08:04 AM, Ruslan Baratov via cmake-developers wrote: >>> >>>> I guess it is a well known fact that cmake command is almost never >>>> executed alone and for non-trivial examples usually hold some extra >>>> arguments (home directory, build directory, verbosity level, toolchains, >>>> options, ...). Also I guess that such commands doesn't change from >>>> day-to-day development process and an obvious way to reduce typing is to >>>> create wrapper build scripts (.bat or .sh, I personally use a Python >>>> one). >>>> >>> Sorry, I don't think something like this belongs upstream. It can easily >>> be done with shell aliases or other custom scripts. >>> >> I've got quite opposite experience. It's hard to say that family of >> custom scripts (+ a lot of environment variables in .bashrc) is an "easy >> shell scripting", example: >> * >> https://github.com/ruslo/polly/blob/162cd157d1d05261a7a708435197d883c4209005/bin/build.py >> >> We shouldn't increase the complexity of the CMake command line >>> interface further. >>> >> To be clear this feature required only one new CMake option. The rest is >> responsibility of some pre-build parsing module. >> >> In general I feel sad that CMake will not became more user-friendly in >> this exact part. Though the only proves of my point that can be provided >> here is a users experience. Since I don't see any feedback here I'm out of >> arguments... >> >> Ruslo >> >> -- >> >> 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> >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake-developers >> > > >
-- 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