[cmake-developers] CMake aliasing system

[Ruslan Baratov]

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" 
--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 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/20160315/c32c6bdb/attachment.html>