Re: [Development] FreeBSD / Clang / Raspberry Pi

[Laszlo Agocs]

Hello,

The device specs indeed assume cross-compiling (after all it's just a shorthand 
for -xplatform plus some common stuff to avoid duplication in the specs for 
each device) but note how for instance the linux-nuc-g++ device spec is used to 
build for an Intel device on an Intel host using an Intel compiler and sysroot. 
The architecture being the same all the way is not interesting, what matters is 
that there is a separate compiler and sysroot.

Therefore this won't be suitable in your case.

Introducing freebsd-clang-rasp-pi as a plain makespec works but does not sound 
very appealing as it is step back to the structure of device-specific makespecs 
from pre-Qt5 times. One alternative, out of my head, would be to add the 
support next to freebsd-clang and use -device-option with some custom, 
freebsd-clang-specific variable to trigger the RPi/ARM specifics - by doing a 
conditional include() for the RPi-specific snippet (or whatever device was 
specified, hence this would work just fine once you need to add FreeBSD support 
for some other device as well). Or something along these lines.

Best regards,
Laszlo



From: Development  on 
behalf of Sylvain Garrigues 
Sent: Tuesday, May 17, 2016 10:50 PM
To: development@qt-project.org
Subject: [Development] FreeBSD / Clang / Raspberry Pi

Hello,

I have ported Qt 5.6 to FreeBSD / Raspberry Pi and would like to share my 
config. I have a question though.

I have created a « device » mkspec (mkspecs/device/freebsd-rasp-pi-clang/ to 
follow the scheme) and I am using it with '-platform freebsd-clang -device 
freebsd-rasp-pi-clang’ but technically *I am not cross-compiling* as either the 
port is built on the Pi or it will later be on the FreeBSD packages building 
infrastructures which runs QEMU arm simulators which emulate a complete arm 
system (filesystem, kernel, etc). Therefore it’s always an arm compiler 
producing arm binaries on a freebsd system - no cross compiling.

So should I just create a mkspecs/freebsd-clang-rasp-pi/ in the top mkspecs 
folder and just use -platform freebsd-clang-rasp-pi? (no -device option)

I can see that using a device is triggering a cross_compile qmake feature with 
configure, and it has side effects (e.g. no stripping) - hence the question.

Happy to hear your thoughts.

Sylvain.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New Qt 5.7.0 RC snapshot available

[Ralf Nolden]

Am Mittwoch, 18. Mai 2016, 15:04:24 schrieb Kai Koehne:
> It's the first time I hear someone asking for a tarball for QtQuick1. 
> 
> I see that people are still stuck with WebKit for some use cases, because
> the 
 architecture, OS requirements and API of WebEngine differs. For
> QtQuick, it's IMO really painless to update. Also, last time I checked,
> there were very little  Linux packages left that still require Qt Quick 1.
> So what's your use case?

https://www.freshports.org/x11-toolkits/qt5-declarative/

(qt5-declarative is a misleading name for qtquick1 as the qt4 version was 
named declarative, however it is the qtquick1 sources packaged).

We will have to check if those ports that depend on qtquick1 do really need 
them (where qt5 (metaport) and qtcreator can go obviously anyway) or if we can 
find another solution.


> 
> Regards
> 
> Kai
> 

-- 
Kind regards,

Ralf Nolden

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

Re: [Development] New Qt 5.7.0 RC snapshot available

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Ralf Nolden
> [...]
> I suggest having a look at https://bugreports.qt.io/browse/QTBUG-49883
> and do some consideration how to handle those issues. If modules are
> deprecated but should still work for backwards compatibility, then there
> should be no change at all that prevents that.

There's a difference between deprecated and unsupported.

Deprecated means we don't advice you to start _new_ projects with it,
Otherwise it has the same promises as any other module.

Unsupported means it's not part of Qt anymore.

> Otherwise that module is
> "somewhat supported even if we don't like to" - which creates a really
> confusing situation for packagers and porters, but (at least I) can live with
> that as long as we get updated (tagged) release tarballs :)

QtQuick1 and QtWebKit are _not_ supported anymore since Qt 5.6. 

What we have said is that we will provide QtWebKit source packages as courtesy 
on a  best-effort basis. That is, also the QtWebKit source package under

http://download.qt.io/community_releases/5.6/5.6.0/

is not part of Qt anymore, and not supported. Use it at your own risk.
There's also no promise we can continue providing these.

> So, an updated tarball for qtquick1 for 5.6 would be really much appreciated
> (so that it works with 5.6.x and 5.7.x)

It's the first time I hear someone asking for a tarball for QtQuick1. 

I see that people are still stuck with WebKit for some use cases, because the 
architecture, OS requirements and API of WebEngine differs. For QtQuick, 
it's IMO really painless to update. Also, last time I checked, there were very 
little  Linux packages left that still require Qt Quick 1. So what's your use
case?

Regards

Kai

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

Re: [Development] ListView and spaces QTBUG-46488

[Filippo Cucchetto]

Maybe they're two different issues because in
https://bugreports.qt.io/browse/QTBUG-46488
it doesn't seem to be related to the number of items shown.
But anyway these are really important bugs for those who use ListView+QAIM

2016-05-18 13:38 GMT+02:00 Stephen Kelly via Development <
development@qt-project.org>:

>
> This can also be reproduced with ListView instead of TreeView:
>
>  https://bugreports.qt.io/browse/QTBUG-53263
>
> Thanks,
>
> Stephen
>
>
> On 18/05/16 12:21, Filippo Cucchetto wrote:
>
> Hello everyone,
> i would like to warn about this serious bug in QDeclarative that could hit
> users of ListViews with QAIM
> https://bugreports.qt.io/browse/QTBUG-46488
> I know that Gabriel gave it a look some time ago but he seems to be quite
> busy right now. I also gave it a look on my own but a quick fix is a no
> go. Furthermore
> some knownledge of the internals of QtDeclarative are needed.
>
> --
> Filippo Cucchetto
>
>
> ___
> Development mailing 
> listDevelopment@qt-project.orghttp://lists.qt-project.org/mailman/listinfo/development
>
>
> --
> Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany
> Management Board: Gerhard Behles, Jan Bohl
> Chair of the Supervisory Board: Uwe Struck
> Registered Office: Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>


-- 
Filippo Cucchetto
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] dev CI integration stuck for 3½ days

[Oswald Buddenhagen]

On Wed, May 18, 2016 at 08:08:46AM +, Simon Hausmann wrote:
> How it is possible that a new staging branch was created while another
> change remained in 'INTEGRATING' state is a mystery to me. Perhaps
> something happened in Gerrit at that moment? Perhaps there's a bug in
> the CI that allows for creating this "impossible" state?
> 
well, something weird definitely *did* happen with gerrit around that
time, as it's also when it started dropping notification mails.
whether/how that is related is unknown to me.

generally, i wouldn't trust that the staging-related commands do all
necessary sanity checks to prevent an amok-running CI from creating a
bogus state. this should be thoroughly re-examined next time we
forward-port the feature.

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

[Development] QtCon Call for Papers extended

[Olivier Goffart]

Hi, 
The deadline for the QtCon call for paper was extended to the 22nd of May.

https://qtcon.org/cfp

---
This is a Call for Papers to a unique event. KDE Akademy, Qt Contributors' 
Summit, FSFE Summit, KDAB and VideoLAN Dev Days have come together to create 
QtCon 2016, Sept 1 - 4, 2016, to be held in Berlin, Germany.

On Sept 1 there will be a day of Training from KDAB. The conference runs from 
Sept 2 - 4. There will be talks, workshops, Birds of a Feather sessions (BoFs) 
and meetings, contributed to by everyone, as well as the traditional social 
events. KDE Akademy will then continue with BoFs from Monday 5th to Thursday 
8th elsewhere in Berlin.

The conference will be at the bcc, in Berlin, which has the flexibility to run 
a diverse program of events so participants can attend presentations and 
meetings with a great variety of focus and interest. If you are a Qt user, 
you'll get the top quality talks you'd expect from a Qt conference, as well as 
presentations and meetings across each of the participating communities. If 
you normally attend the VideoLAN annual event, you will have access to 
everything you usually expect from that, as well as the opportunity to learn 
what’s new from Qt contributors, KDE and FSFE, and so on.

Attendees who are not members of any of these communities are also welcome to 
join this unique, one-off event and take their pick from the unusually wide 
range of material.

What we are looking for
This brings a difference to the Call for Papers you might be familiar with. 
The reason is that we want presentations, workshop and BoFs that cater for one 
or more of the whole communities of KDE, Qt, VideoLAN, FSFE and the wider Free 
software community. The program aims to present a unified event.

We are asking for talk proposals on topics relevant to this including:

- Collaboration between KDE, the Qt Project and other projects that use KDE or 
Qt
- Design and Usability
- Free software in action: use cases of technology in real life; be it mobile, 
desktop deployments and so on.
- Going multi-platform all the way: from design to distribution
- Improving our soft skills and processes
- Increasing our reach through efforts such as accessibility, promotion, 
translation and localization
- Insights about C++ and QML
- Learning what is new and exciting in Qt
- Open Standards
- Overview of what is going on in the various areas of each of the communities
- Presentation of new applications; new features and functions in existing 
applications
- Quality and testing of applications
- Using KDE Frameworks 5 for Qt developers
- Writing custom Qt Quick components using OpenGL

Don't let this list restrict your ideas though. You can submit a proposal even 
if it doesn't fit the list of topics as long as it is relevant

Proposal guidelines
Provide the following information on the proposal form:

- Title—the title of your session/presentation
- Abstract—a brief summary of your presentation
Description—information about your topic and its potential benefits for the 
audience
- A short bio—including anything that qualifies you to speak on your subject
- Tags—add appropriate tags to your proposal to help the committee sort 
through the categories of proposals

We encourage you to rehearse your presentation well. If you don't have someone 
to test your talk on or would like help practising your presentation, you can 
ask the Program Committee

Proposals must be submitted by May 22nd, 23:59:59 CEST.

QtCon will attract people from all over the world. For this reason, all talks 
are in English. Please don't let this requirement stop you. Your ideas and 
commitment are what your audience will want to know about.

- Lightning talks are 10 minutes long
- Other talks are 30 or 60 minutes
- Workshops, BoFs and meetings can be between 1 and 2 hours (Proposals for KDE 
after the weekend will be collected separately)
Workshops and talks include time for Q Lightning talks do not have Q

QtCon has a tight schedule, so beginning and ending times are enforced.

If your presentation must be longer than the standard time, please provide 
reasons why this is so. For lightning talks, we will be collecting all of the 
presentations the day before the lightning track. All of the presentations 
will be set-up and ready to go at the start of the lightning track.

QtCon is upbeat, but it is not frivolous. Help us see that you care about your 
topic, your presentation and your audience. Typos, sloppy or all-lowercase 
formatting and similar appearance oversights leave a bad impression and may 
count against your proposal. There's no need to overdo it. If it takes more 
than two paragraphs to get to the point of your topic, it's too much and 
should be slimmed down. The quicker you can make a good impression, the 
better.

We are looking for originality. Having the same people talking about the same 
things doesn't accomplish that goal. Thus, we favor original and novel 
content. If you have presented on 

Re: [Development] ListView and spaces QTBUG-46488

[Stephen Kelly via Development]

This can also be reproduced with ListView instead of TreeView:

 https://bugreports.qt.io/browse/QTBUG-53263


Thanks,

Stephen

On 18/05/16 12:21, Filippo Cucchetto wrote:

Hello everyone,
i would like to warn about this serious bug in QDeclarative that could hit
users of ListViews with QAIM
https://bugreports.qt.io/browse/QTBUG-46488
I know that Gabriel gave it a look some time ago but he seems to be quite
busy right now. I also gave it a look on my own but a quick fix is a 
no go. Furthermore

some knownledge of the internals of QtDeclarative are needed.

--
Filippo Cucchetto


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


--
Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany
Management Board: Gerhard Behles, Jan Bohl
Chair of the Supervisory Board: Uwe Struck
Registered Office: Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838

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

Re: [Development] New Qt 5.7.0 RC snapshot available

[Ralf Nolden]

Am Mittwoch, 18. Mai 2016, 04:44:45 schrieb Jani Heikkinen:

Hi, thanks for the snapshot that allows us some build tests before any 
releases.

I just hit a compile error on the deprecated qtquick1 module, latest src 
tarball is for 5.5.1. For qtwebkit, there's the community releases subdir:
http://download.qt.io/community_releases/5.6/5.6.0/
(which does work)

I suggest having a look at https://bugreports.qt.io/browse/QTBUG-49883
and do some consideration how to handle those issues. If modules are 
deprecated but should still work for backwards compatibility, then there 
should be no change at all that prevents that. Otherwise that module is 
"somewhat supported even if we don't like to" - which creates a really 
confusing situation for packagers and porters, but (at least I) can live with 
that as long as we get updated (tagged) release tarballs :)

So, an updated tarball for qtquick1 for 5.6 would be really much appreciated 
(so that it works with 5.6.x and 5.7.x)

Thanks :)


> Hi all,
> 
> 
> New Qt 5.7.0 RC snapshot available
> 
> 
> Windows: http://download.qt.io/snapshots/qt/5.7/5.7.0-rc/456/
> 
> Linux: http://download.qt.io/snapshots/qt/5.7/5.7.0-rc/424/
> 
> Mac: http://download.qt.io/snapshots/qt/5.7/5.7.0-rc/354/
> 
> src: http://download.qt.io/snapshots/qt/5.7/5.7.0-rc/latest_src/submodules/
> 
>  />
> 
> 

-- 
Kind regards,

Ralf Nolden

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

[Development] ListView and spaces QTBUG-46488

[Filippo Cucchetto]

Hello everyone,
i would like to warn about this serious bug in QDeclarative that could hit
users of ListViews with QAIM
https://bugreports.qt.io/browse/QTBUG-46488
I know that Gabriel gave it a look some time ago but he seems to be quite
busy right now. I also gave it a look on my own but a quick fix is a no go.
Furthermore
some knownledge of the internals of QtDeclarative are needed.

-- 
Filippo Cucchetto
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt + GCC 6 no joy ?

[Bogdan Vatra]

Yep, looks very "familiar"!

On Wednesday 18 May 2016 10:08:31 Liang Qi wrote:
> https://bugreports.qt.io/browse/QTBUG-53373 ?
> 
> On 18 May 2016 at 10:01, Bogdan Vatra  wrote:
> > Hi,
> > 
> > Did anyone tried Qt (5.7) with GCC 6 ?
> > I compiled Qt and QtCreator (using debian's gcc 6) but it crashes in v4
> > when I
> > start QtCreator :(. It's a know issue or just me?
> > 
> > Cheers,
> > BogDan.
> > 
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] dev CI integration stuck for 3½ days

[Simon Hausmann]

The best theory I can come up with at this point looks like this:

Once there was a "newer" staging branch that contained changes that were still 
in 'STAGED' state but another change was in 'INTEGRATING' (which
was in the _previous_ staging branch), the conditions for an endless "loop" 
were met, I think. Upon any of the CI restarts, the CI thought it would
"resume" the integration of the one change that was in 'INTEGRATING' state and 
picked up from the latest staging branch, which had the other (two or three)
changes that were still in 'STAGED' state. When the build finished (pass or 
fail), the staging-approve command must have failed. It failed for me when I 
tried
to manually "reject" the changes - that's when I realized the discrepancy. 
However the change that was in 'INTEGRATING' state remained, because the staging
branch that we tried to approve/reject did not contain that change, so nothing 
changed there. As the state of the 'INTEGRATING' and 'STAGED' changes didn't
change, the CI didn't pick up any new integrations or try to create new staging 
branches.

How it is possible that a new staging branch was created while another change 
remained in 'INTEGRATING' state is a mystery to me. Perhaps something happened
in Gerrit at that moment? Perhaps there's a bug in the CI that allows for 
creating this "impossible" state?

Simon

From: Development  on 
behalf of Jędrzej Nowacki 
Sent: Wednesday, May 18, 2016 9:42:41 AM
To: development@qt-project.org
Subject: Re: [Development]  dev CI integration stuck for 3½ days

Yes and I fixed them all on Friday with a "catch all" command. I have no clue
how just one integration could stay locked.

Cheers,
 Jędrek

On Tuesday 17 of May 2016 12:49:17 Oswald Buddenhagen wrote:
> On Tue, May 17, 2016 at 06:08:50AM +, Simon Hausmann wrote:
> > I just looked into it and it looks like an inconsistency in the gerrit
> > database. The latest builds branch points to a set of changes that are in
> > staged state, while the change that is in integrating change is not in
> > that branch. I've found the build branch that had the integrating change
> > and rejected the change (and staged it again).
> yes, fregl (or nierob?) diagnosed that there was a network outage during
> the time the CI was supposed to report the result to gerrit, and the
> system apparently has no queue/retry mechanism for this. so it's out of
> sync now.
> Somebody (TM) needs to (re-)execute the relevant commands by hand ...
>
> > It appears that the change was staged Friday morning and nobody noticed it
> > during Friday. Then came a long weekend, with Monday off and Tuesday also
> > off in Norway.
> >
> > Simon
> > 
> > From: Development
> >  on behalf of
> > Thiago Macieira  Sent: Monday, May 16, 2016
> > 10:42:32 PM
> > To: development@qt-project.org
> > Subject: [Development] dev CI integration stuck for 3½ days
> >
> > Will someone PLEASE look into the qtbase/dev integration?
> >
> > https://codereview.qt-project.org/156523 has been integrating for (at the
> > time of writing this email) 84 and a half hours -- 3.5 days -- and that's
> > including two full working days in Finland, one in Germany and Norway as
> > today is is a bank holiday in those countries. I believe we'll break the
> > record by the time someone gets around to fixing this, if we haven't yet.
> >
> > Let's not hope we have to wait until after tomorrow's holiday in Norway
> > for it to get back to working.
> >
> > --
> > Thiago Macieira - thiago.macieira (AT) intel.com
> >
> >   Software Architect - Intel Open Source Technology Center
> >
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Qt + GCC 6 no joy ?

[Liang Qi]

https://bugreports.qt.io/browse/QTBUG-53373 ?

On 18 May 2016 at 10:01, Bogdan Vatra  wrote:

> Hi,
>
> Did anyone tried Qt (5.7) with GCC 6 ?
> I compiled Qt and QtCreator (using debian's gcc 6) but it crashes in v4
> when I
> start QtCreator :(. It's a know issue or just me?
>
> Cheers,
> BogDan.
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt + GCC 6 no joy ?

[Bogdan Vatra]

Hi,

Did anyone tried Qt (5.7) with GCC 6 ? 
I compiled Qt and QtCreator (using debian's gcc 6) but it crashes in v4 when I  
start QtCreator :(. It's a know issue or just me?

Cheers,
BogDan.

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

Re: [Development] dev CI integration stuck for 3½ days

[Jędrzej Nowacki]

Yes and I fixed them all on Friday with a "catch all" command. I have no clue 
how just one integration could stay locked.

Cheers,
 Jędrek

On Tuesday 17 of May 2016 12:49:17 Oswald Buddenhagen wrote:
> On Tue, May 17, 2016 at 06:08:50AM +, Simon Hausmann wrote:
> > I just looked into it and it looks like an inconsistency in the gerrit
> > database. The latest builds branch points to a set of changes that are in
> > staged state, while the change that is in integrating change is not in
> > that branch. I've found the build branch that had the integrating change
> > and rejected the change (and staged it again).
> yes, fregl (or nierob?) diagnosed that there was a network outage during
> the time the CI was supposed to report the result to gerrit, and the
> system apparently has no queue/retry mechanism for this. so it's out of
> sync now.
> Somebody (TM) needs to (re-)execute the relevant commands by hand ...
> 
> > It appears that the change was staged Friday morning and nobody noticed it
> > during Friday. Then came a long weekend, with Monday off and Tuesday also
> > off in Norway.
> > 
> > Simon
> > 
> > From: Development
> >  on behalf of
> > Thiago Macieira  Sent: Monday, May 16, 2016
> > 10:42:32 PM
> > To: development@qt-project.org
> > Subject: [Development] dev CI integration stuck for 3½ days
> > 
> > Will someone PLEASE look into the qtbase/dev integration?
> > 
> > https://codereview.qt-project.org/156523 has been integrating for (at the
> > time of writing this email) 84 and a half hours -- 3.5 days -- and that's
> > including two full working days in Finland, one in Germany and Norway as
> > today is is a bank holiday in those countries. I believe we'll break the
> > record by the time someone gets around to fixing this, if we haven't yet.
> > 
> > Let's not hope we have to wait until after tomorrow's holiday in Norway
> > for it to get back to working.
> > 
> > --
> > Thiago Macieira - thiago.macieira (AT) intel.com
> > 
> >   Software Architect - Intel Open Source Technology Center
> > 
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] FreeBSD / Clang / Raspberry Pi

[Sylvain Garrigues]

Sure I will share with Oleksandr, my work is based on what he has already done 
anyway, just couldn’t wait to try to port other modules on my Pi :-)

I dug into the build process and noticed what I explained about the -device and 
the detection of the cross_compile feature, but anyway I let you discuss the 
side effects later. Will join you on #kde-freebsd.

Have a good day

  
> Le 18 mai 2016 à 07:21, Ralf Nolden  a écrit :
> 
> Hi Sylvain,
> 
> You may want to get in contact with Oleksandr who has also done a porting:
> http://kernelnomicon.org/?p=598
> 
> Olelksandr is in the process of merging his additions to the dev branch while 
> I'm doing the ports integration in the meanwhile by using patches to the 
> freebsd ports at https://freebsd.kde.org/ and merging our ports patches to Qt.
> 
> You may want to join us on #kde-freebsd so we can find the solution that we 
> end 
> up without any patches in ports. 
> 
> From the qt perspective things like the pi are devices so for consistency 
> that 
> should land in the devices section (I think Oleksandr has done it that way, 
> you may compare your patch with his one on his website). For any side 
> effects, 
> we should discuss whatever is the best solution here.
> 
> One thing that should work out of the box is using qtcreator.
> 
> Am Dienstag, 17. Mai 2016, 22:50:59 schrieb Sylvain Garrigues:
>> Hello,
>> 
>> I have ported Qt 5.6 to FreeBSD / Raspberry Pi and would like to share my
>> config. I have a question though.
>> 
>> I have created a « device » mkspec (mkspecs/device/freebsd-rasp-pi-clang/ to
>> follow the scheme) and I am using it with '-platform freebsd-clang -device
>> freebsd-rasp-pi-clang’ but technically *I am not cross-compiling* as either
>> the port is built on the Pi or it will later be on the FreeBSD packages
>> building infrastructures which runs QEMU arm simulators which emulate a
>> complete arm system (filesystem, kernel, etc). Therefore it’s always an arm
>> compiler producing arm binaries on a freebsd system - no cross compiling.
>> 
>> So should I just create a mkspecs/freebsd-clang-rasp-pi/ in the top mkspecs
>> folder and just use -platform freebsd-clang-rasp-pi? (no -device option)
>> 
>> I can see that using a device is triggering a cross_compile qmake feature
>> with configure, and it has side effects (e.g. no stripping) - hence the
>> question.
>> 
>> Happy to hear your thoughts.
>> 
>> Sylvain.
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> 
> -- 
> Kind regards,
> 
> Ralf Nolden
> 

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