[cmake-developers] Deprecating qt4_use_modules and qt4_automoc?

[Marcus D. Hanwell]

On Wed, Feb 6, 2013 at 8:21 AM, David Cole <dlrdave at aol.com> wrote:
> -----Original Message-----
> From: Stephen Kelly <steveire at gmail.com>
> To: cmake-developers <cmake-developers at cmake.org>
> Sent: Wed, Feb 6, 2013 8:17 am
> Subject: Re: [cmake-developers] Deprecating qt4_use_modules and qt4_automoc?
>
> David Cole wrote:
>
>> I agree with Marcus. There's no reason to deprecate these (other than
>> deprecating Qt4 entirely, but not yet) unless there's a significant code
>> clarity advantage.
>
> I think in the case of the qt4_automoc macro at least, there's some
> technical issue with changes in dependencies. Alex knows more.
>
>> What does it buy us to deprecate these things now?
>
> Good advice in documentation I guess, if there's technical reasons not to
> use them. From a porting point of view (in terms of porting to newer cmake
> or newer Qt), it might be easier if they are not used (provided a new enough
> cmake version is used).
>
> It's never too early to have one eye on porting, and if the documentation
> tells you that using a macro makes porting harder, you can take note :).
> Also, if starting a new project, it makes sense to not use stuff (from the
> beginning) that will not be available/is not recommended/has disadvantages.
> For that though, there needs to be some indication of what is deprecated.
>
>
> OK, sure. If something's not recommended moving forward, by all means
> document it that way.
>
> "Deprecation" to me means more of an active warning against using something
> at runtime, or producing an error if something is used that is not
> recommended.
>
> But if you are advising just updating docs, then go for it.

I entirely echo Dave's words here - I thought you meant more of an
active warning against using it at runtime/producing errors. If all
you mean is updating the documentation I think that is a great idea,
and it certainly seems like the right way to go here.

Marcus