[PySide] About the next PySide release
Hugo Parente Lima
Just raising a small issue: We have enough bug fixes to do a release but due
to this long transition to qt-projects plus the guys that didn't accepted the
CLA for they patches, mostly of the bugfixes are on github repository and the
github repository already differs a lot from the gitorious and gerrit
repositories so the question is:
Should I do a release based on which repository? The most recent github with
new bugs fixed or the gerit without the new fixes plus minor regressions due
to people that didn't accepted the CLA?
A hard choice... because if I do the release based on github I'll have a nice
PySide release with plenty of bugs fixed but what to do next release? i.e. it
doesn't really solves the problem.
If I go for gerrit, maybe there's not even enough fixes for a release plus I
don't want to spend my free time at home doing the re-work of applying patches
and solving conflicts on the new repository instead of fixing new bugs.
While there's not a complete answer for that I can't do a release and PySide
stays in this limbo with active development but without a release :-/, for
sure PySide can't be that way forever.
To increase the mess yesterday I pushed commits into Shiboken to simplify
PySide releases and development, ApiExtractor is now a static library and
GeneratorRunner is no more, so you will only need two repositories to compile
PySide, the one for the generator (Shiboken) and PySide itself.
Comments, opinions, whatever about this issue is appreciated.
Regards.
--
Hugo Parente Lima
matti....@nokia.com
In my opinion, the regressions need to be fixed before a release can be made. As I see it, though, it should take almost no time to fix the regression bugs if we just get volunteers, and once they're fixed, re-applying the commits from the github fork back to the main repo should be no issue whatsoever because I expect the changes after the fixes to be minimal compared to the old repos.
If the release would be made from Github, the exact history would be lost once the commits are merged back to the main repo.
So, I would wait until we have received fixes for the regression bugs, then merge the Github changes back to Gerrit, and then make the release based on that codebase. This would also provide a nice incentive for getting the regression bugs fixed. :-)
Cheers,
ma.
> _______________________________________________
> PySide mailing list
> PyS...@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/pyside
_______________________________________________
PySide mailing list
PyS...@qt-project.org
http://lists.qt-project.org/mailman/listinfo/pyside
paulo alcantara
On Wed, Feb 29, 2012 at 2:58 PM, Hugo Parente Lima
<hugo...@openbossa.org> wrote:
>
> Hi,
>
> Just raising a small issue: We have enough bug fixes to do a release but due
> to this long transition to qt-projects plus the guys that didn't accepted the
> CLA for they patches, mostly of the bugfixes are on github repository and the
> github repository already differs a lot from the gitorious and gerrit
> repositories so the question is:
>
> Should I do a release based on which repository? The most recent github with
> new bugs fixed or the gerit without the new fixes plus minor regressions due
> to people that didn't accepted the CLA?
>
There's some people waiting for the new PySide release based on the recently
bugs fixed available on the github repository - some of them are important and
should be possibly part of the new release, IMO.
> A hard choice... because if I do the release based on github I'll have a nice
> PySide release with plenty of bugs fixed but what to do next release? i.e. it
> doesn't really solves the problem.
>
> If I go for gerrit, maybe there's not even enough fixes for a release plus I
> don't want to spend my free time at home doing the re-work of applying patches
> and solving conflicts on the new repository instead of fixing new bugs.
>
I agree with you.
> While there's not a complete answer for that I can't do a release and PySide
> stays in this limbo with active development but without a release :-/, for
> sure PySide can't be that way forever.
>
I think that a new release is kind of *urgent* currently.
> To increase the mess yesterday I pushed commits into Shiboken to simplify
> PySide releases and development, ApiExtractor is now a static library and
> GeneratorRunner is no more, so you will only need two repositories to compile
> PySide, the one for the generator (Shiboken) and PySide itself.
>
This will really make our life easier. Great work, Hugo!
> Comments, opinions, whatever about this issue is appreciated.
>
> Regards.
>
> --
> Hugo Parente Lima
>
> _______________________________________________
> PySide mailing list
> PyS...@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/pyside
>
- Paulo Alcantara
anatoly techtonik
+1 on everything above. There is no reason to delay release, because
those legal fixes are only matter for Qt Project, not for PySide
users. Moreover I see no reasons why Git experts can not replay
patches from GitHub back to Gerrit to keep it in sync while we are
seeking volunteers for these Qt Project fixes.
On Wed, Feb 29, 2012 at 10:07 PM, <matti....@nokia.com> wrote:
>
> If the release would be made from Github, the exact history would be lost once the commits are merged back to the main repo.
I don't understand what history will be lost? Tags? Yes, the hash will
change and the release will be broken, and if I understand correctly,
every tag in new Gerrit repository is broken now, because some
changesets are absent from history. Am I right?
--
anatoly t.
anatoly techtonik
Are there any prospects on possible release date?
Spyder IDE still can not be started with PySide 1.1.0 on Linux
http://bugs.pyside.org/show_bug.cgi?id=1105
And Spyder users are suffering from Windows-specific bug with PySide
1.0.9+ that I can not repeat on Linux:
http://code.google.com/p/spyderlib/issues/detail?id=897
Hugo Parente Lima
> Hello guys,
>
> Are there any prospects on possible release date?
We need to backport everything on github to the code on gerrit, when this
finish we can finally release a new version.
I'm occupied with other projects too, so at the moment I can't promise any
dead line for a PySide release.
> Spyder IDE still can not be started with PySide 1.1.0 on Linux
> http://bugs.pyside.org/show_bug.cgi?id=1105
>
> And Spyder users are suffering from Windows-specific bug with PySide
> 1.0.9+ that I can not repeat on Linux:
> http://code.google.com/p/spyderlib/issues/detail?id=897
>
> --
> anatoly t.
--
Hugo Parente Lima
INdT - Instituto Nokia de Tecnologia
anatoly techtonik
<hugo...@openbossa.org> wrote:
> On Wednesday 07 March 2012 05:20:18 anatoly techtonik wrote:
>> Hello guys,
>>
>> Are there any prospects on possible release date?
>
> We need to backport everything on github to the code on gerrit, when this
> finish we can finally release a new version.
1. [ ] find the last common ancestor
With HG I would do:
hg clone git://gitorious.org/pyside/pyside.git
cd pyside
hg inc --template '{node}' -l 1 git://github.com/PySide/PySide.git
2. [ ] Make new clone and import revisions starting after the hash
from the step above into Mercurial Queue
cd ..
hg clone git://github.com/PySide/PySide.git pyside2
cd pyside2
hg qimport -r HASH:HEAD
hg qpop -a
cp -r .hg/patches ../pyside/.hg/
cd ../pyside
hg qpush -a
hg qfinish -a
Unfortunately, after Matti flattened the repository history this won't
work anymore and we need to find this common revision manually. On the
second thought even if the history was there, the hashes would be
reindexed after history edition anyway, so we still have to inspect it
manually. In any case, I think that a bad move to kill the project
history.
anatoly techtonik
It appears that neither me, nor Matti knows how to properly strip
those offending revisions from the Git history. Rebasing doesn't work,
because subsequent merges screw up everything. So, unless somebody
possess required know how, I am afraid we will have to stick with the
way things currently are.
Hugo Parente Lima
> On Wed, Mar 7, 2012 at 8:39 PM, Hugo Parente Lima
>
> <hugo...@openbossa.org> wrote:
> > On Wednesday 07 March 2012 05:20:18 anatoly techtonik wrote:
> >> Hello guys,
> >>
> >> Are there any prospects on possible release date?
> >
> > We need to backport everything on github to the code on gerrit, when this
> > finish we can finally release a new version.
>
> 1. [ ] find the last common ancestor
> With HG I would do:
> hg clone git://gitorious.org/pyside/pyside.git
> cd pyside
> hg inc --template '{node}' -l 1 git://github.com/PySide/PySide.git
>
> 2. [ ] Make new clone and import revisions starting after the hash
> from the step above into Mercurial Queue
> cd ..
> hg clone git://github.com/PySide/PySide.git pyside2
> cd pyside2
> hg qimport -r HASH:HEAD
> hg qpop -a
> cp -r .hg/patches ../pyside/.hg/
> cd ../pyside
> hg qpush -a
> hg qfinish -a
We can use "git format-patch" then "git am" to apply the patches and hope for
no conflicts.
> Unfortunately, after Matti flattened the repository history this won't
> work anymore and we need to find this common revision manually. On the
> second thought even if the history was there, the hashes would be
> reindexed after history edition anyway, so we still have to inspect it
> manually. In any case, I think that a bad move to kill the project
> history.
I think the flattened history was maybe the only point that make me feel
against the move to qt-projects, the history really helps when developing,
it's the documentation of the project, when you don't know what a piece of
code does you just look at the history of those lines and see the commit
comments, reference for bugs in bugzilla, who wrote the changes, etc... and
now all this was gone :-/. Matti told me about a magic script that would do
that, I didn't see it and a doubt that it would be on pair with the own git
commands. I was talking with Renato days ago about it and he have the same
feelings, besides looking at git history with the lack of commits last weeks I
see that wasn't only me with this feeling.
IMO Gerrit isn't the best tool, isn't too user friendly, requires a password
for everything, i.e. it have their problems, but nothing that we can't get
used to (like we were used to bugzilla), unfortunately due to Nokia that owns
the name PySide (Matti, correct if I'm wrong) we can't just stick on git hub,
using their own bug tracking system and maybe even web server that github
offers, this would be perfect from the developer point of view (at least my
point of view), no moves, no changes the project would go on without
headaches... but we (pyside developers) can't do that, because doing that will
start the bizarre situation where all original developers forked the project
and no developers left on the official project. I *really* don't want this to
happen.
I still have the plan to do a rebase removing the offending commits from each
repository, solve the conflicts by hand then ask for a approval to push the
changes to gerrit send to Matti for approval, after that I'll finally feel
comfortable to continue to hack on PySide, but this takes times and I have not
much free time to code, so would be better to send my time fixing bugs rather
doing this code-bureaucracy stuff :-(.
Commits are the pulse of any project, developers are the heart, no developers
means no commits that means no pulse that means a dead project.
Hugo Parente Lima
Ok, first step done!
I rebased over 632 commits to remove the offending commit on Shiboken and
pushed the changes to a personal branch on github.
The offending commit was: c3059779d7628fdbb140ed02cdc0cc7ca80e7ad8
Matti can you check if everything is ok? then I can re-apply the tags (because
the hashes changed) and apply the fixes on gerrit on top of this branch and
finally force-push it to gerrit with all history glory built-in! :-D
The rebased tree without the offending commit can be found at branch "clafix"
on https://github.com/hugopl/Shiboken
I didn't the same on ApiExtractor because I can't figure out what was the
offending commit hash.
If everyone agree with this I can do the same on PySide and ApiExtractor too.
Hugo Parente Lima
Second step done!
I rebased PySide removing the two offending commits and pushed the tree to the
"clafix" branch of my PySide clone on github
(https://github.com/hugopl/PySide)
The offending commits were:
- 0d60daf1e1a6edd95b58c7bdd33da8f4c1629c90
- 32681f7b7039f41bec4c4965370d4b66bee53532
By what I saw GeneratorRunner doesn't had any problems with missing CLA
agreement, then the only missing repository is ApiExtractor.
Matti, do you still have the git hash annotated somewhere?
Matti Airas
> Ok, first step done!
>
> I rebased over 632 commits to remove the offending commit on Shiboken and
> pushed the changes to a personal branch on github.
>
> The offending commit was: c3059779d7628fdbb140ed02cdc0cc7ca80e7ad8
>
> Matti can you check if everything is ok? then I can re-apply the tags (because
> the hashes changed) and apply the fixes on gerrit on top of this branch and
> finally force-push it to gerrit with all history glory built-in! :-D
>
> The rebased tree without the offending commit can be found at branch "clafix"
> on https://github.com/hugopl/Shiboken
>
> I didn't the same on ApiExtractor because I can't figure out what was the
> offending commit hash.
>
> If everyone agree with this I can do the same on PySide and ApiExtractor too.
Wow, that was a heroic effort! Big kudos to you!
To me, both both Shiboken and PySide clafix branches look just fine - go
ahead with it!
The last problematic commit on Apiextractor is:
c2a35449016e3d5873f3e1657df51e2ff854cd2e
And yes, GeneratorRunner is good as-is.
Since the submitted changes in Gerrit are commits in a special ref, just
make sure that when force-pushing the history back to Gerrit, those
commits are not lost (I'm not sure how git works wrt force-pushing...).
BTW, how did you actually do the removal? Did you just branch the repos
before the offending commits and then merge all commits except the
offending ones?
Cheers,
ma.
Anderson Lizardo
> BTW, how did you actually do the removal? Did you just branch the repos
> before the offending commits and then merge all commits except the
> offending ones?
I wonder if a " git rebase -i commit_id^ " (where "commit_id" is the
commit to be removed) and removing the line on the interactive rebase
editor, would fix this more or less easily :)
Anyway, it's done and let's hope development can progress :)
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
Matti Airas
> On Fri, Mar 9, 2012 at 8:40 AM, Matti Airas<matti....@nokia.com> wrote:
>> BTW, how did you actually do the removal? Did you just branch the repos
>> before the offending commits and then merge all commits except the
>> offending ones?
> I wonder if a " git rebase -i commit_id^ " (where "commit_id" is the
> commit to be removed) and removing the line on the interactive rebase
> editor, would fix this more or less easily :)
That was the approach I tried, but that breaks down in merges. Couldn't
quite figure out what the exact problem was, though.
Cheers,
ma.
Hugo Parente Lima
> On 09.03.2012 15:12, ext Anderson Lizardo wrote:
> > On Fri, Mar 9, 2012 at 8:40 AM, Matti Airas<matti....@nokia.com>
wrote:
> >> BTW, how did you actually do the removal? Did you just branch the repos
> >> before the offending commits and then merge all commits except the
> >> offending ones?
> >
> > I wonder if a " git rebase -i commit_id^ " (where "commit_id" is the
> > commit to be removed) and removing the line on the interactive rebase
> > editor, would fix this more or less easily :)
>
> That was the approach I tried, but that breaks down in merges. Couldn't
> quite figure out what the exact problem was, though.
I did
git rebase -i --preserve-merges commit_id~1
Removed the commit and went on fixing the conflicts taking care to not
recreate the fix done by the removed commit by mistake.
I guess just one merge of shiboken had problems and went "inlined", the other
were preserved as well.
> Cheers,
>
> ma.
Hugo Parente Lima
> > On Fri, Mar 9, 2012 at 8:40 AM, Matti Airas<matti....@nokia.com>
wrote:
> >> BTW, how did you actually do the removal? Did you just branch the repos
> >> before the offending commits and then merge all commits except the
> >> offending ones?
> >
> > I wonder if a " git rebase -i commit_id^ " (where "commit_id" is the
> > commit to be removed) and removing the line on the interactive rebase
> > editor, would fix this more or less easily :)
>
> That was the approach I tried, but that breaks down in merges. Couldn't
> quite figure out what the exact problem was, though.
>
> Cheers,
>
> ma.
Work done...
.. but gerrit, oh gerrit... I can't push the changes because I don't have
permissions to push merge commits:
Counting objects: 2086, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (935/935), done.
Writing objects: 100% (2086/2086), 715.24 KiB, done.
Total 2086 (delta 1459), reused 1476 (delta 1135)
remote: Resolving deltas: 100% (1459/1459)
To ssh://hug...@codereview.qt-project.org:29418/pyside/apiextractor.git
! [remote rejected] master -> master (you are not allowed to upload merges)
error: failed to push some refs to 'ssh://hug...@codereview.qt-
project.org:29418/pyside/apiextractor.git'
anatoly techtonik
<hugo...@openbossa.org> wrote:
> On Friday 09 March 2012 10:14:25 Matti Airas wrote:
>> On 09.03.2012 15:12, ext Anderson Lizardo wrote:
>> > On Fri, Mar 9, 2012 at 8:40 AM, Matti Airas<matti....@nokia.com>
> wrote:
>> >> BTW, how did you actually do the removal? Did you just branch the repos
>> >> before the offending commits and then merge all commits except the
>> >> offending ones?
>> >
>> > I wonder if a " git rebase -i commit_id^ " (where "commit_id" is the
>> > commit to be removed) and removing the line on the interactive rebase
>> > editor, would fix this more or less easily :)
>>
>> That was the approach I tried, but that breaks down in merges. Couldn't
>> quite figure out what the exact problem was, though.
>>
>> Cheers,
>>
>> ma.
>
> Work done...
Just when I thought I found something.. =)
http://linux.die.net/man/1/git-filter-branch
Take a look at `git filter-branch --commit-filter`. Is it better than rebase?
--
anatoly t.
paulo alcantara
The execellent work that Hugo has been doing (even with no much spare
time to do it) is already done.
anatoly techtonik
http://qt.gitorious.org/pyside/pyside/commits/master
--
anatoly t.
Matti Airas
> Work done...
>
> .. but gerrit, oh gerrit... I can't push the changes because I don't have
> permissions to push merge commits:
>
> Counting objects: 2086, done.
> Delta compression using up to 2 threads.
> Compressing objects: 100% (935/935), done.
> Writing objects: 100% (2086/2086), 715.24 KiB, done.
> Total 2086 (delta 1459), reused 1476 (delta 1135)
> remote: Resolving deltas: 100% (1459/1459)
> To ssh://hug...@codereview.qt-project.org:29418/pyside/apiextractor.git
> ! [remote rejected] master -> master (you are not allowed to upload merges)
> error: failed to push some refs to 'ssh://hug...@codereview.qt-
> project.org:29418/pyside/apiextractor.git'
>
I sent you private mail with contact information of the Qt admin who has
performed the previous clone/push operations for me.
IMHO, I don't think it's a bad policy to disallow all direct pushes to
the git repo. That at least enforces that every commit has passed review
(and CI testing, if we'd integrate them to the Qt infra, as well), and I
regard that as a good thing. It just causes trouble in the initial
setup, but the Qt admins have been very fast to help with any issues so far.
Hugo Parente Lima
> I can't confirm that - there are no changes in the Gitorious repository.
> http://qt.gitorious.org/pyside/pyside/commits/master
Is done, but locally because I had problems uploading the repository tree to
gerrit.
--
Matti Airas
> On Monday 12 March 2012 06:02:49 anatoly techtonik wrote:
>> I can't confirm that - there are no changes in the Gitorious repository.
>> http://qt.gitorious.org/pyside/pyside/commits/master
> Is done, but locally because I had problems uploading the repository tree to
> gerrit.
... and now they're there, with JP's bugfixes, and even the Gitorious
mirror has already been updated! Thanks a million, Hugo, for the effort!
Cheers,
ma.
Hugo Parente Lima
> On 12.03.2012 15:11, ext Hugo Parente Lima wrote:
> > On Monday 12 March 2012 06:02:49 anatoly techtonik wrote:
> >> I can't confirm that - there are no changes in the Gitorious repository.
> >> http://qt.gitorious.org/pyside/pyside/commits/master
> >
> > Is done, but locally because I had problems uploading the repository tree
> > to gerrit.
>
> ... and now they're there, with JP's bugfixes, and even the Gitorious
> mirror has already been updated! Thanks a million, Hugo, for the effort!
I also did the merge of GeneratorRunner and ApiExtractor into Shiboken, so
GeneratorRunner and ApiExtractor repositories can now be considered deprecated
and newer Shiboken packages doesn't need to depend on them..
All history of ApiExtractor and GeneratorRunner were merged into Shiboken
repository.
Now there are just two failing tests blocking the release, both related to
QtWebKit, despite of the fact that I need to check if all is working on a
Windows and Mac machine.
Matti Airas
> I also did the merge of GeneratorRunner and ApiExtractor into Shiboken, so
> GeneratorRunner and ApiExtractor repositories can now be considered deprecated
> and newer Shiboken packages doesn't need to depend on them..
OK, that's neat. :-) I guess we can just let the repos stay around as
memoirs...
> All history of ApiExtractor and GeneratorRunner were merged into Shiboken
> repository.
Oh, that's cool! I think the first time you did it, you just copied the
files over?
> Now there are just two failing tests blocking the release, both related to
> QtWebKit, despite of the fact that I need to check if all is working on a
> Windows and Mac machine.
You might want to mention that on the mailing list and ask some
Windows/Mac developers to help with building the head and running the
tests - that'd save you some boring work and get others involved. At the
moment, I think we need all the help we can from other people...
Hugo Parente Lima
> On 15.03.2012 15:42, ext Hugo Parente Lima wrote:
> > I also did the merge of GeneratorRunner and ApiExtractor into Shiboken,
> > so GeneratorRunner and ApiExtractor repositories can now be considered
> > deprecated and newer Shiboken packages doesn't need to depend on them..
>
> OK, that's neat. :-) I guess we can just let the repos stay around as
> memoirs...
Yes, they must still around.
> > All history of ApiExtractor and GeneratorRunner were merged into Shiboken
> > repository.
>
> Oh, that's cool! I think the first time you did it, you just copied the
> files over?
No, the first time I did I also merged the histories.
> > Now there are just two failing tests blocking the release, both related
> > to QtWebKit, despite of the fact that I need to check if all is working
> > on a Windows and Mac machine.
>
> You might want to mention that on the mailing list and ask some
> Windows/Mac developers to help with building the head and running the
> tests - that'd save you some boring work and get others involved. At the
> moment, I think we need all the help we can from other people...
Not just boring work, but I don't have how to test on a mac or Windows
machines right now, the Windows issue is solvable but I can't say the same
about mac.
Tim Doty
Matti Airas
> You might want to mention that on the mailing list and ask some
> Windows/Mac developers to help with building the head and running the
> tests - that'd save you some boring work and get others involved. At
> the moment, I think we need all the help we can from other people...
Haha! Didn't realize the mailing list was CCd. Oops. :-)
Matti Airas
What is actually involved for testing on the mac? Is there a test suite to run or what?
Cheers,
ma.
Jason McCampbell
_______________________________________________
PySide mailing list
PyS...@qt-project.org
http://lists.qt-project.org/mailman/listinfo/pyside
Jason McCampbell
Matti Airas
Well, I need to update my Mac and Windows builds anyway so I'll run the tests. Gitorious master (http://qt.gitorious.org/pyside/pyside/commits/master) is now the master repo? I have a couple of crash fixes I had submitted to GitHub that I'll verify are or are not in the Gitorious repo as well.
Gitorious is a read-only mirror of the Gerrit repo. I'm not quite sure how often it is mirrored, though (hourly or daily). But it should be recent enough, in any case.
Cheers,
ma.
Jason McCampbell
_______________________________________________
PySide mailing list
PyS...@qt-project.org
http://lists.qt-project.org/mailman/listinfo/pyside
anatoly techtonik
> On 12.03.2012 15:11, ext Hugo Parente Lima wrote:
>> On Monday 12 March 2012 06:02:49 anatoly techtonik wrote:
>>> I can't confirm that - there are no changes in the Gitorious repository.
>>> http://qt.gitorious.org/pyside/pyside/commits/master
>> Is done, but locally because I had problems uploading the repository tree to
>> gerrit.
>
> ... and now they're there, with JP's bugfixes, and even the Gitorious
> mirror has already been updated! Thanks a million, Hugo, for the effort!
+1
And even GitHub mirror has been updated. ;)
--
anatoly t.
John Ehresman
> On Thursday 15 March 2012 12:28:52 Matti Airas wrote:
>> Hugo might want to correct me, but just go to the build directory and
>> run "ctest" and report the results together with your configuration
>> details on the mailing list.
>
> just ctest works, but "ctest -V" is better because it prints a lot of things
> useful to know what failed.
I just get a message that no test configuration file is found when I try
this on Windows, either in the root of the pyside source or the build
directory where cmake is run. Do I need to run ctest from another
directory or is there another way to run the tests?
Thanks,
John
Hugo Parente Lima
> On 3/15/12 2:03 PM, Hugo Parente Lima wrote:
> > On Thursday 15 March 2012 12:28:52 Matti Airas wrote:
> >> Hugo might want to correct me, but just go to the build directory and
> >> run "ctest" and report the results together with your configuration
> >> details on the mailing list.
> >
> > just ctest works, but "ctest -V" is better because it prints a lot of
> > things useful to know what failed.
>
> I just get a message that no test configuration file is found when I try
> this on Windows, either in the root of the pyside source or the build
> directory where cmake is run. Do I need to run ctest from another
> directory or is there another way to run the tests?
You need to run on build directory, I don't remember if the tests were
disabled by default on windows builds, but in any case you can enabled then
passing: -DBUILD_TESTS=ON on cmake (on both, PySide and Shiboken).
> Thanks,
>
> John
John Ehresman
> On 3/15/12 2:03 PM, Hugo Parente Lima wrote:
>> On Thursday 15 March 2012 12:28:52 Matti Airas wrote:
>>> Hugo might want to correct me, but just go to the build directory and
>>> run "ctest" and report the results together with your configuration
>>> details on the mailing list.
>>
>> just ctest works, but "ctest -V" is better because it prints a lot of things
>> useful to know what failed.
>
> I just get a message that no test configuration file is found when I try
> this on Windows, either in the root of the pyside source or the build
> directory where cmake is run. Do I need to run ctest from another
> directory or is there another way to run the tests?
Oops, I had disabled tests when building to reduce compilation time and
am rebuilding now.
Sorry for not checking this first,