Re: [Qt-creator] Fakevim does not work as expected whe n replacing a word
On Sunday 18 April 2010 09:50:42 ext Andre Poenitz wrote:
On Sun, Apr 18, 2010 at 10:58:34AM +1000, Brad Hubbard wrote:
Not sure how comprehensive fakevim emulation is supposed to be but
when attempting yank inner word yiw the fakevim plugin interprets
the i as the input mode command. this also effects commands like viw
and viwp which can be handy for replacing a word with yanked text.
If this support is not planned how are others replacing a word with
yanked text? I can of course use a register and cw but that's a bit
long winded as is s/word/newword/. I suppose I could get motivated
and try to implement this myself but maybe this is on someone's to do
list?
There is no plan. Features are added as soon as someone needs them and
finds the time to implement it.
There is already support for 'diw', making 'yiw' work might be a matter
of copying/tweaking five or six lines. And, of course, a contribution
would be highly welcome ;-)
I just took the liberty to add the half line needed to make yiw work:
static bool subModeCanUseTextObjects(int submode)
{
-return submode == DeleteSubMode;
+return submode == DeleteSubMode || submode == YankSubMode;
}
But it looks like the text object area still needs quite a bit of work.
Andre'
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] qt-creator master and Maemo development
Hi, I pulled and built qt-creator master branch and installed the latest MADDE 0.6.14. First I tried a minimal application: I created a new project hello-world using the Mobile Qt Application wizard. I didn't change anything. When I built the application I get an error message: unfortunately, the publicly available MADDE uses an outdated dh_make that requires your project to reside in a directory whose name is of the form project-name-version. As a workaround, you should rename your directory accordingly. A new version of MADDE should be available soon. Christian ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] build settings for cross platform? multiple svn checkouts on each development computer
The .pro file is all you need. Compiler settings, include paths, build steps, versioning and more can all be specified here. You also MUST use the pro file to specify library link and project dependencies. It's not possible to do this via the Project screen (the dependency settings merely sets the build order - an application dependant on a library in the same session will NOT be linked to it). I actually prefer having these settings inside the readable .pro text file. It's better than the MSVC solution that requires hunting through dozens of tiny model dialogs. Up until now I've found the pro.user file to be totally expendable. In fact it has occasionally broken my projects (Creator not being able to find the executable to run for example, or problems building). However, I've noticed that the latest snapshots turn on the shadow build feature by default. This is a problem because it overrides the build paths specified in the .pro file. And if I turn off the feature it will be turned on again the next time the .pro.user is generated (ie. when someone checks out my code). I hope Nokia revert this to the previous behavior (turn off shadow builds by default). On Mon, Apr 19, 2010 at 4:18 AM, Coda Highland c...@bobandgeorge.comwrote: The makefile is generated directly from the .pro file. This is where everything needs to go, especially if you want your project to work if you're building it at the command line instead of from within Creator. The .pro.user file is really just intended for short-term, system-specific, non-general details that aren't intended to be shared with other users of the source code. The only thing that's broken is that it's not clear from the way Creator's UI is laid out that this is the case, and it has to be explained like this. Basically, what you need to keep in mind is that Creator is first and foremost a tool for writing code and creating software, not for managing projects. /s/ Adam On Sun, Apr 18, 2010 at 9:35 PM, nobodyhere pem.accounts.s...@gmail.com wrote: This makes Qt Creator sound broken? I mean, what's the point of having it generate your make files for you (in the .pro.user file), if you have to then rewrite them manually anyway (in the .pro file)? regards - Original Message - From: Coda Highland c...@bobandgeorge.com To: qt-creator@trolltech.com Sent: Sunday, April 18, 2010 8:45:29 PM GMT -06:00 US/Canada Central Subject: Re: [Qt-creator] build settings for cross platform? multiple svn checkouts on each development computer No, we mean the .pro file. qmake's file format supports a lot of logic there, including platform detection (scopes like win32, unix, and macx). Never edit the .pro.user file and avoid using Creator's built-in tools for changing the build settings -- do all the work directly in the .pro file except for things that are SPECIFICALLY relevant to only the checkout you're working on. /s/ Adam On Sun, Apr 18, 2010 at 7:32 PM, nobodyhere pem.accounts.s...@gmail.com wrote: You mean edit and (svn commit) the project's .pro.user file? (Not the project's .pro file?) And the .pro file has hardcoded / absolute paths in it, so how does this let me do a simple (svn checkout and build that just works, with the exact same .pro.user file) for (multiple computers) and (multiple checkouts on the same computer)? Is it required to manually edit the .pro.user XML file's text? thank you for any leads - Original Message - From: Danny Price deepblue...@googlemail.com To: qt-creator@trolltech.com Sent: Sunday, April 18, 2010 9:21:30 AM GMT -06:00 US/Canada Central Subject: Re: [Qt-creator] build settings for cross platform? multiple svn checkouts on each development computer Set you build settings, project directories and platform-specific configs in the .pro file. On 18 Apr 2010, at 09:26, nobodyhere wrote: Is there information on how to (svn commit) cross platform (Windows, Mac, Linux) build settings for a Qt Creator project, that doesn't have any absolute paths? I created a new project on Windows, then (svn commit) it. Then I did (svn checkout) of the project on Mac OS. Unfortunately, I had to create a new set of build settings to get it to build / compile? But it seems to be storing this build settings stuff in the [project].pro.user file, with absolute paths? How can I fix it so that I can simplify for anyone to do multiple fresh (svn checkout)'s of the project on each machine (regardless of OS), and have the build / compile just work (for Windows, Mac, Linux builds) (with multiple checkouts per machine, using relative paths)? Why are there absolute paths in this [project].user.pro file (for example, the buildDirectory has an absolute path)? thank you for any leads ___ Qt-creator mailing list Qt-creator@trolltech.com
[Qt-creator] QT Creator Usability
I am using Qt Creator in my C++ lectures. All pupils like the tool, but there is a little distraction: All windows my be closed with the little X in the top right corner -- actually it is all but one: if you change to debug (which may happen by accident) there is no X and a lot of confusion. I would like to suggest such an X to switch back to edit mode. Regards August Hörandl -- August Hörandl No keyboard present august.hoera...@gmx.at Hit F1 to continue Zen engineering? -- Jim Griffith ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] build settings for cross platform? multiple svn checkouts on each development computer
Hi Danny! Yes, using the .pro-file for settings to be shared between developers is the right thing to do. Thanks for explaining that so well! On 19.04.2010 10:16, ext Danny Price wrote: However, I've noticed that the latest snapshots turn on the shadow build feature by default. This is a problem because it overrides the build paths specified in the .pro file. And if I turn off the feature it will be turned on again the next time the .pro.user is generated (ie. when someone checks out my code). Can you please describe your directory layout? Are you using your own shadow building setup? Which variables are ignored by our use of shadow builds? Can you send us a .pro-file that breaks for you so that we can improve the situation? A existing in-source build should get detected and get imported using the settings used to create the build. This is of course not a help in the fresh-checkout use-case you mention:-/ I hope Nokia revert this to the previous behavior (turn off shadow builds by default). We did turn on shadow-building by default since we need to improve the multiple platform use-case. That is a real pain with pre-2.0beta creators since switching platforms totally confuses make, thus resulting in broken builds and all kinds of strangeness. There is just too many complaints about this to ignore;-). So shadow-building is -- from our perspective -- a must have for the next version. However we are open for suggestions on how to minimize the impact on other use-cases. Best Regards, Tobias -- Tobias Hunger Software Engineer Nokia, Qt Development Frameworks Nokia gate5 GmbH Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B Umsatzsteueridentifikationsnummer: DE 812 845 193 Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] QT Creator Usability
Hello August! On 19.04.2010 10:21, ext August Hörandl wrote: I am using Qt Creator in my C++ lectures. All pupils like the tool, but there is a little distraction: All windows my be closed with the little X in the top right corner -- actually it is all but one: if you change to debug (which may happen by accident) there is no X and a lot of confusion. I would like to suggest such an X to switch back to edit mode. Would you please be so kind and add your suggestions and bugreports to our issue tracking system at http://bugreports.qt.nokia.com/ We are currently preparing for the beta release and in times like this suggestions made in the mailing lists sometimes are just forgotten about:-/ Best Regards, Tobias -- Tobias Hunger Software Engineer Nokia, Qt Development Frameworks Nokia gate5 GmbH Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B Umsatzsteueridentifikationsnummer: DE 812 845 193 Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] pro file parsing in cumulative mode really necessary?
Hi,
I didn't find any negative side effects, so I ask myself whether
cumulative mode here is really beneficial for anything at all?
Yes it is. In cumulative mode the following is parsed as if both if
branches are taken, regardless of platform.
win32 {
SOURCES += process_win.cpp
}
unix {
SOURCRS += process_unix.cpp
}
The cumulative mode is based on the linguist parsing of .pro files which
tries to find all the releveant source files regardless of scoping.
In master and thus in the 2.0 final and the not yet released beta we
parse the .pro files twice (completly oversimplified) and thus should
handle your case correctly.
I'd aprreciate if you could report after the beta if that is indeed the
case.
Another side-note: qmake seems to accept the following (admittedly
strange) call
OUTPUT=$$replace(INPUT,string,)
and interprets it as to replace string by in $$INPUT. However, the
implementation in profileevaluator.cpp sets OUTPUT to the empty string
instead.
I'll let our qmake expert comment on that.
And please report any discrepancies between our parser and qmake's one,
those are interesting for us.
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] QT Creator Usability
Am Montag 19 April 2010 schrieb Tobias Hunger: Hello August! On 19.04.2010 10:21, ext August Hörandl wrote: I am using Qt Creator in my C++ lectures. All pupils like the tool, but there is a little distraction: All windows my be closed with the little X in the top right corner -- actually it is all but one: if you change to debug (which may happen by accident) there is no X and a lot of confusion. I would like to suggest such an X to switch back to edit mode. Would you please be so kind and add your suggestions and bugreports to our issue tracking system at http://bugreports.qt.nokia.com/ http://bugreports.qt.nokia.com/browse/QTCREATORBUG-1214 Regards August Hörandl -- August Hörandl august.hoera...@gmx.at The heart of the UNIX philosophy is the idea that the power of a system comes more from the relationships among programs than from the programs themselves. --Kernighan ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] pro file parsing in cumulative mode really necessary?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 19.04.2010 11:48, schrieb Oswald Buddenhagen:
On Sat, Apr 17, 2010 at 01:39:19AM +0200, ext Tilman Vogel wrote:
that's because cumulative mode will effectively make SRCDIR = ../src
../src
which will then expand to include(../src ../src/abc/def.pri) which is
obviously bogus.
Right and I guess, the right thing would be to do the concatting as a
cartesian product, i.e. if SRCDIR = { ../srcA, ../srcB }, then the
include should get an array as argument { ../srcA/abc/def.pri,
../srcB/abc/def.pri } (or rather be called for each of them).
the combined parsing daniel mentioned will solve the particular issue
that nothing is included at all, but it will miss the other possible
values of SCRDIR which are not in the current build configuration.
to make creator-friendly projects, try to avoid such clever constructs.
instead, make distinct complete include statementes which are executed
conditionally.
That's unfortunately not always possible if you have other constraints
like different build configurations.
OUTPUT=$$replace(INPUT,string,)
However, the implementation in profileevaluator.cpp sets OUTPUT to the
empty string instead.
how did you determine that?
using some qDebug() calls in profileevaluator.cpp.
I was using such a replace call to initialize yet
another directory variable (stripping of some trailing part of the
path) and this not working caused my source files not to be found.
Tilman
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
iEYEARECAAYFAkvMSgUACgkQ9ZPu6Yae8lkDqgCfQzi6R4p7BHxN8BUz+eSNyAxd
HvEAn1dP59PDAt4dbQ+zwjhvKmalGPte
=zaRH
-END PGP SIGNATURE-
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] pro file parsing in cumulative mode really necessary?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 19.04.2010 11:02, schrieb Daniel Teske:
Yes it is. In cumulative mode the following is parsed as if both if
branches are taken, regardless of platform.
win32 {
SOURCES += process_win.cpp
}
unix {
SOURCRS += process_unix.cpp
}
The cumulative mode is based on the linguist parsing of .pro files which
tries to find all the releveant source files regardless of scoping.
Sorry, didn't comment on that in my first reply. Thanks for the hint.
I see that you want to collect all SOURCES. In this case, you could just
go ahead and evaluate both branches because the statement itself is
actually appending, but I understand that there are cases like this
win32 {
APPENDIX = win
}
unix {
APPENDIX = unix
}
SOURCES += process_$${APPENDIX}.cpp
and then just evaluating both branches will miss win, so = needs to
be cumulative too, but I guess the only solution is then to really use a
cartesian product because even now, this will give
SOURCES += process_win unix.cpp
instead of
SOURCES += process_win.cpp process_unix.cpp
(didn't try this one).
Tilman
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
iEYEARECAAYFAkvMTNIACgkQ9ZPu6Yae8ll+QgCggUHPF/yHWj4t6a2OMqi66hak
ZvYAniqGnhw5usa6QcsUXqqd+443zzyD
=NN1c
-END PGP SIGNATURE-
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] build settings for cross platform? multiple svn checkouts on each development computer
As a thought... How troublesome would it be to have something like a CREATOR_PRAGMA variable in the .pro file that directs these kinds of things? qmake could simply ignore it, after all. This would allow some settings -- like, for instance, shadow builds -- to be overridden by the .pro file. /s/ Adam On Mon, Apr 19, 2010 at 3:49 AM, Tobias Hunger tobias.hun...@nokia.com wrote: Hi Danny! Yes, using the .pro-file for settings to be shared between developers is the right thing to do. Thanks for explaining that so well! On 19.04.2010 10:16, ext Danny Price wrote: However, I've noticed that the latest snapshots turn on the shadow build feature by default. This is a problem because it overrides the build paths specified in the .pro file. And if I turn off the feature it will be turned on again the next time the .pro.user is generated (ie. when someone checks out my code). Can you please describe your directory layout? Are you using your own shadow building setup? Which variables are ignored by our use of shadow builds? Can you send us a .pro-file that breaks for you so that we can improve the situation? A existing in-source build should get detected and get imported using the settings used to create the build. This is of course not a help in the fresh-checkout use-case you mention:-/ I hope Nokia revert this to the previous behavior (turn off shadow builds by default). We did turn on shadow-building by default since we need to improve the multiple platform use-case. That is a real pain with pre-2.0beta creators since switching platforms totally confuses make, thus resulting in broken builds and all kinds of strangeness. There is just too many complaints about this to ignore;-). So shadow-building is -- from our perspective -- a must have for the next version. However we are open for suggestions on how to minimize the impact on other use-cases. Best Regards, Tobias -- Tobias Hunger Software Engineer Nokia, Qt Development Frameworks Nokia gate5 GmbH Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B Umsatzsteueridentifikationsnummer: DE 812 845 193 Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] build settings for cross platform? multiple svn checkouts on each development computer
I think the settings in the .pro file should always take priority. This is allows for automated builds and builds outside of Creator. It shouldn't be muddied up to handle Creator special-cases. That sets a precedent. I'm not sold on the idea that Creator must turn on shadow builds by default. If it's an issue as stated by Tobias, why not simple turn it on in via the Project screen/pro.user file for the projects that require it as was the case previously? The functionality is identical. Tobias, your statement seems to imply that the Nokia/Qt devs are also throwing away their pro.user files to get builds working which is the underlying issue. If that's the case, why not fix pro.user files once and for all? Fix the problem at source? On Mon, Apr 19, 2010 at 2:56 PM, Coda Highland c...@bobandgeorge.comwrote: As a thought... How troublesome would it be to have something like a CREATOR_PRAGMA variable in the .pro file that directs these kinds of things? qmake could simply ignore it, after all. This would allow some settings -- like, for instance, shadow builds -- to be overridden by the .pro file. /s/ Adam On Mon, Apr 19, 2010 at 3:49 AM, Tobias Hunger tobias.hun...@nokia.com wrote: Hi Danny! Yes, using the .pro-file for settings to be shared between developers is the right thing to do. Thanks for explaining that so well! On 19.04.2010 10:16, ext Danny Price wrote: However, I've noticed that the latest snapshots turn on the shadow build feature by default. This is a problem because it overrides the build paths specified in the .pro file. And if I turn off the feature it will be turned on again the next time the .pro.user is generated (ie. when someone checks out my code). Can you please describe your directory layout? Are you using your own shadow building setup? Which variables are ignored by our use of shadow builds? Can you send us a .pro-file that breaks for you so that we can improve the situation? A existing in-source build should get detected and get imported using the settings used to create the build. This is of course not a help in the fresh-checkout use-case you mention:-/ I hope Nokia revert this to the previous behavior (turn off shadow builds by default). We did turn on shadow-building by default since we need to improve the multiple platform use-case. That is a real pain with pre-2.0beta creators since switching platforms totally confuses make, thus resulting in broken builds and all kinds of strangeness. There is just too many complaints about this to ignore;-). So shadow-building is -- from our perspective -- a must have for the next version. However we are open for suggestions on how to minimize the impact on other use-cases. Best Regards, Tobias -- Tobias Hunger Software Engineer Nokia, Qt Development Frameworks Nokia gate5 GmbH Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B Umsatzsteueridentifikationsnummer: DE 812 845 193 Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
[Qt-creator] Closing non-modal dialog
Hi,
A short question about proper way of shutdown-ing a plug-in.
In situation when, from QtCreator plugin named ScreenShotToolPlugin, non-modal
dialog is opened, when QTCreator is closed, shutdown function from respective
plugin is not called until the moment the non-modal dialog is explicitly
closed. Is there any way for plugin to get notification about close event of
QtCreator or some other way to close non-modal dialog created from plugin when
QTCreator is closed?
class MainDlg;
class ScreenShotToolPlugin : public ExtensionSystem::IPlugin
{
Q_OBJECT
public:
void shutdown();
private:
MainDlg * dlg;
private slots:
void openDialog()
{
dlg = new MainDlg();
dlg-show();
}
};
Best Regards,
Goran
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] pro file parsing in cumulative mode really necessary?
On Mon, Apr 19, 2010 at 02:18:13PM +0200, ext Tilman Vogel wrote:
Right and I guess, the right thing would be to do the concatting as a
cartesian product, i.e. if SRCDIR = { ../srcA, ../srcB }, then the
include should get an array as argument { ../srcA/abc/def.pri,
../srcB/abc/def.pri } (or rather be called for each of them).
this might work in *this* case. the complete solution is akin to solving
the halting problem ...
the general solution is evaluating each pro file with every possible
branch taken and not taken. that of course has unmanageable complexity.
on top of that, there are external inputs which the evaluator simply
cannot anticipate.
i think this might work more or less: instead of evaluating the rest of
the file from each branch point, evaluate everything just once and tag
every assignment with the current scope. each following statement which
has a data dependency would be executed once for each tagged variant,
restricted by compatibility with the own scope (i.e., there is no point
in evaluating win32-tagged data in a unix scope).
of course, this tagging alone is quite a science (assuming
win32/unix/macx aren't sufficient), and there is still the external
uncertainty. also, i'm not sure how that would fare with loops
complexity-wise.
all in all, i'd really like to try that, but i might have a hard time
convincing my managers to pay for it. ;)
OUTPUT=$$replace(INPUT,string,)
However, the implementation in profileevaluator.cpp sets OUTPUT to the
empty string instead.
funny, i just found the same bug independently. :)
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] qt-creator master and Maemo development
Renaming the directory doesn't help. Due to source code of qt4projectmanager plugin it always adds the string _0.1 to the name of the base directory before it starts dh_make. I tried to generate the debian directory with a manual call of dh_make after I renamed the directory. The debian directory is correctly created but then some copy command of the binary fails (again due to some version-in-name-is-wrong problem). With some renaming I managed to create a .deb file but this had no binaries in it - again because of that versioning problem :( Ok, I give up with Qt Creator and MADDE until a new version of MADDE is released. I will try if I can get the SDK running... Regards, Jochen Am Montag, den 19.04.2010, 09:55 +0200 schrieb christian.kande...@nokia.com: Hi, I pulled and built qt-creator master branch and installed the latest MADDE 0.6.14. First I tried a minimal application: I created a new project hello-world using the Mobile Qt Application wizard. I didn't change anything. When I built the application I get an error message: unfortunately, the publicly available MADDE uses an outdated dh_make that requires your project to reside in a directory whose name is of the form project-name-version. As a workaround, you should rename your directory accordingly. A new version of MADDE should be available soon. Christian ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] qt-creator master and Maemo development
Forget my former reply. If I use a shadow built, name the directory name-version and create the debian folder with dh_make manually then built succeeds and creates a deployable .deb file. Now my first Qt application is running on my N900! Qt 4.5.3 seems not be ready for N900 to publish applications - I will try to use Qt 4.6.2. Any idea when MADDE for Qt 4.6.2 will be released? It would also be nice to have a MADDE with Qt 4.7 so we can start developing programs for that Qt version. Regards, Jochen Am Montag, den 19.04.2010, 09:55 +0200 schrieb christian.kande...@nokia.com: Hi, I pulled and built qt-creator master branch and installed the latest MADDE 0.6.14. First I tried a minimal application: I created a new project hello-world using the Mobile Qt Application wizard. I didn't change anything. When I built the application I get an error message: unfortunately, the publicly available MADDE uses an outdated dh_make that requires your project to reside in a directory whose name is of the form project-name-version. As a workaround, you should rename your directory accordingly. A new version of MADDE should be available soon. Christian ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] pro file parsing in cumulative mode really necessary?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 19.04.2010 22:27, schrieb Oswald Buddenhagen:
On Mon, Apr 19, 2010 at 02:18:13PM +0200, ext Tilman Vogel wrote:
Right and I guess, the right thing would be to do the concatting as a
cartesian product, i.e. if SRCDIR = { ../srcA, ../srcB }, then the
include should get an array as argument { ../srcA/abc/def.pri,
../srcB/abc/def.pri } (or rather be called for each of them).
this might work in *this* case. the complete solution is akin to solving
the halting problem ...
Ok, maybe the approach looking at all the branches is just too much. Why
not define a set of configurations (maybe based on qmake.conf files the
user may pick) and just parse the pro file for every configuration once
in non-cumulative mode and then concat all the results? Sounds a lot
less complex. To me it seems, the pro file parsing tries to be a bit too
clever. Probably the evaluation of the given set of configurations could
even be done efficiently in one pass.
Tilman
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
iEYEARECAAYFAkvM39UACgkQ9ZPu6Yae8lkclwCfewi51EgOPMFLn6doB1LpHhaR
jFAAoIqPS6jM2HueVgJNqXxziPrU0k3Y
=fc8a
-END PGP SIGNATURE-
___
Qt-creator mailing list
Qt-creator@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-creator
