Re: [Development] Summary of renaming changes

2012-10-19 Thread Matt Williams
On 19 October 2012 12:29, Oswald Buddenhagen
oswald.buddenha...@digia.com wrote:
 On Fri, Oct 19, 2012 at 11:00:04AM +, Sune Vuorela wrote:
 On 2012-10-19, Alberto Mardegan ma...@users.sourceforge.net wrote:
  3) Provide a script to switch, per user and maybe even per $PWD, what
  version of Qt /usr/bin/qmake should generate the makefiles for.

 I have, as a distributor, frequently gotten 'hate' in #qt for providing
 switchable qmakes.

 using (debian style) altenatives for that is pretty stupid.

 using a menu function which manipulates PATH in the current shell is
 exactly the right thing to do. that's the ominious qset some trolls
 have been talking about.

There is also 'modules' (http://modules.sourceforge.net/) which is
used at my University to achieve a similar thing.

-- 
Matt Williams
http://milliams.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] FW: Alpha 2 this week or skip it

2012-06-01 Thread Matt Williams
On 1 June 2012 15:54, Joerg Bornemann joerg.bornem...@nokia.com wrote:
 On 01/06/2012 15:30, ext Thiago Macieira wrote:
 Allright, I take back everything. MS actually announced the RC of Visual
 Studio 2012 yesterday:
 http://blogs.msdn.com/b/visualstudio/archive/2012/05/31/visual-studio-2012-r
 c-available-now.aspx This seems to be identical to the formerly announced
 Visual Studio 11. Thus support is in Qt. Just use the win32-msvc11 mkspec.

 We should rename the mkspec.

 I agree...if that's really the final product name. ;-)

Don't forget that the Microsoft Visual Studio and Microsoft Visual
C(++) version number don't have to match. The Visual Studio number
are generally years (recently: 2005, 2008, 2010 and now 2012) while
Visual C(++) is numbered more normally (respectively: 8.0, 9.0 10.0
and now probably 11.0). So the new one could be Visual Studio 2012
with Visual C++ compiler 11.0. Also, in future Microsoft are planning
decoupling the IDE from the compiler so we should keep the mkspec
following the compiler I guess.

-- 
Matt Williams
http://milliams.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] RFC: The Future of QDoc

2012-02-09 Thread Matt Williams
On 9 February 2012 14:15, Keno Fischer ke...@stanford.edu wrote:
 Implement a new C++ parser

 Any plans on using Clang a parser? The wiki page mentioned Qt Creator's AST,
 but it seems like Qt Creator will be moving away from its own implementation
 in the future, so I think that might be something to consider. Also, since
 the necessary work on Clang is being done for Qt Creator anyway (I'm
 thinking of things like signals/slots) it might be worth to keep qdoc in
 mind when working on Clang for Qt Creator. Any thoughts?

There's also the KDevelop C++ parser. It already supports many C++11
features and run very fast. As far as I'm aware it doesn't depends on
any KDE libraries (Qt only) and already has the ability to extract
Doxygen-style comments. I don't know if there are any KDevelop people
on this list who can comment further?

-- 
Matt Williams
http://milliams.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Installing Qt5Config.cmake from the Qt repo?

2011-10-28 Thread Matt Williams
On 28 October 2011 14:44,  lars.kn...@nokia.com wrote:
 Hi Stephen,

 On 10/28/11 1:13 PM, ext Stephen Kelly stephen.ke...@kdab.com wrote:


Hi,

== Summary ==

I'm considering adding some cmake files to Qt, which would be installed
by Qt,
and which would make it easier for CMake based projects to depend on Qt.

I'm CC'ing the cmake developers too see what they think of the idea too.

== Clarification ==

To avoid misunderstanding:

* This proposal is not about porting the Qt build system to CMake.
* This would not make Qt depend on CMake at all
* I am proposing to add some plain text files to the Qt repo for
installation
* Those plain text files would need to be generated while building Qt
(using
existing mechanisms, like perl).

== How CMake finds packages ==

(Skip this section if you already know how CMake finds packages)

For those who have not used CMake before, it has two ways to find
dependencies:

* If you want to find a dependency, you write a FindPackage.cmake file
or use
    an existing one. Usually this FindPackage.cmake will not be
installed.

* If you want to be easily found for others to depend on, you write a
    PackageConfig.cmake file and install it to a location CMake will
use to
    find things like that. I assume this is similar to how pkgconfig
works, but
    I have never used pkgconfig.

    This is most common in the case of projects which use CMake
themselves,
    but there's no reason projects which do not use CMake can't provide
    similar files. This becomes even more useful with recent CMake
features
    based on finding packages.

Either way, if someone does this in CMake:

find_package(Package)

the result is the ability to use the headers and libraries from Package.

CMake ships with FindQt4.cmake, so anyone using CMake uses

find_package(Qt4)

to be able to use Qt 4.

== Qt5Config.cmake ==

I propose that we ship a Qt5Config.cmake file with Qt which we install,
along
with macros equivalent to what is currently in Qt4Macros.cmake, and some
Targets.cmake files.

Then find_package(Qt5) in CMake would use that Config file and there
would be no
need for a FindQt5.cmake.

The advantage of this are:

* It allows people using CMake to start experimenting with Qt 5 ports
sooner
* When new features arrive in Qt (such as new libraries like
QtDeclarative was
in Qt 4) we can update the Qt5Config file immediately and test the new
features
more easily.
* We can use the cmake imported targets feature to more easily support
debug
and release versions on Windows.
* KDE does not need a separate FindQt.cmake to the one shipped by CMake.

== Maintainance ==

KDAB (specifically myself) can maintain these CMakes files. We have other
engineers with both Qt and CMake competencies, and there are more people
in
the CMake and KDE communities with cross-competencies.

That is assuming it works of course. I haven't even prototyped yet in
case
there is some reason this shouldn't be done. I'm quite confident it will
work though.



I can't think of any reason this effort should be prevented, but if you
have a
reason, please let me know. I'm looking for early objections before I
start to
do any work.

 I think that's reasonable in general. It's similar to what we do to
 support pkgconfig. I agree with Thiago's comment that this should be split
 and we should have one file per shared library.

I think Stephen's suggestion of having one CMake file for all Qt
Essentials using find_package(Qt5 COMPONENTS QtGui etc...) makes the
most sense, at least for specifying which QtEssential libraries to
build against. It is the way most CMake files like this are done and
is not dissimilar to how the existing FindQt4.cmake works. Whether we
have a separate CMake file for Qt Addons (whether a separate one for
each module of another combined one) becomes a separate issue.

 How is this dependency wise? Would we need to install these files into a
 special location and how do we know where this location is? Does
 supporting the feature require cmake to be installed?

From http://www.cmake.org/cmake/help/cmake2.6docs.html#command:find_package
(page down a little) you have a number of options of where to install
them. For example prefix/(share|lib)/name*/(cmake|CMake)/ where
prefix could be /usr and name could be 'Qt5' so they could be
installed in /usr/share/Qt5/cmake. There's similar special paths on
Windows and Mac.

For the purpose of building and installing Qt we have no dependence on
CMake. As Stephen says the files could just be created from some
templates using a bit of Perl (or whatever you want). For someone
building a project which depends on Qt they would of course need CMake
to find these files.

-- 
Matt Williams
http://milliams.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development