[cmake-developers] CMake aliasing system

Sat Mar 19 08:02:38 EDT 2016

I've openned new issue for further discussion:
* https://github.com/ruslo/CMake/issues/3

On 18-Mar-16 06:24, Tamás Kenéz wrote:
> 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.doe at example.com" 
> <mailto:john.doe at example.com> --branch="master"
> >> git push --remote="git://awesome.example.com <http://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_baratov at yahoo.com <mailto:ruslan_baratov at 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.doe at example.com"
>     <mailto:john.doe at example.com> --branch="master"
>     > git push --remote="git://awesome.example.com
>     <http://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 at cmake.org
>>     <mailto:cmake-developers at 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 <http://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
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160319/c00a24e1/attachment.html>