[cmake-developers] CMake aliasing system

[Tamás Kenéz]

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"
<john.doe at 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_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"
> <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>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
>>
>> 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
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160318/071bc0da/attachment.html>