Qt-interest Archive, August 2006
qmake -zip
Message 1 in thread
Dear List,
I find myself often making zips of my projects by hand in order to move them
over to another machine for testing and building releases. (Theoretically
this could best be done via CVS/subversion, but I don't do that yet.) What
I end up doing is essentially traversing the .pro file and all its included
.pri files by hand, and piling all the needed files into one folder, zipping
it up, going to the other machine, unzipping, and changing the .pro file to
reflect the relocation of everything. How stupid!
I wrote myself a little python script that (recursively) parses .pr{o,i}
files enough to do this for me now, and I just run
propkg.py My.pro <other files> <destdir>
now and it makes destdir/My.zip, but I admittedly hacked it together and
surely there are .pro files that would baffle it. My questions are
1. Has anyone else tackled this same problem and done a better job than I
have?
2. Shouldn't there be a qmake argument that would do this? qmake -zip or
something...maybe there is and I just don't know about it? Some Troll
listening want to add this feature? :)
Nathan
--
[ signature omitted ]
Message 2 in thread
Why would the .pro and .pri files need any changes? All project file
references should be relative to the .pro/.pri files, not absolute paths.
Any path references should be defined via each machine's environment
variables (QTDIR, MYLIBRARYDIR, etc.).
On 08-03-2006 3:11 PM, "Nathan Carter" wrote:
>
> Dear List,
>
> I find myself often making zips of my projects by hand in order to move them
> over to another machine for testing and building releases. (Theoretically
> this could best be done via CVS/subversion, but I don't do that yet.) What
> I end up doing is essentially traversing the .pro file and all its included
> .pri files by hand, and piling all the needed files into one folder, zipping
> it up, going to the other machine, unzipping, and changing the .pro file to
> reflect the relocation of everything. How stupid!
>
> I wrote myself a little python script that (recursively) parses .pr{o,i}
> files enough to do this for me now, and I just run
> propkg.py My.pro <other files> <destdir>
> now and it makes destdir/My.zip, but I admittedly hacked it together and
> surely there are .pro files that would baffle it. My questions are
>
> 1. Has anyone else tackled this same problem and done a better job than I
> have?
>
> 2. Shouldn't there be a qmake argument that would do this? qmake -zip or
> something...maybe there is and I just don't know about it? Some Troll
> listening want to add this feature? :)
>
> Nathan
--
[ signature omitted ]
Message 3 in thread
On 8/3/06 4:28 PM, "Keith Esau" <keith.esau@xxxxxxx> wrote:
> Why would the .pro and .pri files need any changes? All project file
> references should be relative to the .pro/.pri files, not absolute paths.
> Any path references should be defined via each machine's environment
> variables (QTDIR, MYLIBRARYDIR, etc.).
Hmm. Good point. I should probably reorganize this way, shouldn't I?
I guess the only utility my script retains is for zipping up sources for
distribution of the project as source. And for making it easy to carry just
the needed files over to the other machine. But CVS/subversion would
accomplish both those, too, wouldn't they? I guess I should really start
using one of those...
Thanks for the tip.
--
[ signature omitted ]
Message 4 in thread
We did it so everything would work cross-platform, and it works well. I just
got Mac build working, and all fixes were compiler and library related.
Nothing had to change due to file locations.
You're welcome.
On 08-03-2006 3:44 PM, "Nathan Carter" wrote:
>
>
> On 8/3/06 4:28 PM, "Keith Esau" <keith.esau@xxxxxxx> wrote:
>
>> Why would the .pro and .pri files need any changes? All project file
>> references should be relative to the .pro/.pri files, not absolute paths.
>> Any path references should be defined via each machine's environment
>> variables (QTDIR, MYLIBRARYDIR, etc.).
>
> Hmm. Good point. I should probably reorganize this way, shouldn't I?
>
> I guess the only utility my script retains is for zipping up sources for
> distribution of the project as source. And for making it easy to carry just
> the needed files over to the other machine. But CVS/subversion would
> accomplish both those, too, wouldn't they? I guess I should really start
> using one of those...
>
> Thanks for the tip.
--
[ signature omitted ]
Message 5 in thread
Nathan Carter a écrit :
> Dear List,
>
> I find myself often making zips of my projects by hand in order to move them
> over to another machine for testing and building releases. (Theoretically
> this could best be done via CVS/subversion, but I don't do that yet.) What
> I end up doing is essentially traversing the .pro file and all its included
> ..pri files by hand, and piling all the needed files into one folder, zipping
> it up, going to the other machine, unzipping, and changing the .pro file to
> reflect the relocation of everything. How stupid!
>
> I wrote myself a little python script that (recursively) parses .pr{o,i}
> files enough to do this for me now, and I just run
> propkg.py My.pro <other files> <destdir>
> now and it makes destdir/My.zip, but I admittedly hacked it together and
> surely there are .pro files that would baffle it. My questions are
>
> 1. Has anyone else tackled this same problem and done a better job than I
> have?
>
> 2. Shouldn't there be a qmake argument that would do this? qmake -zip or
> something...maybe there is and I just don't know about it? Some Troll
> listening want to add this feature? :)
>
>
There is a make dist target that does some job (packing all files used
by the project and some .prf files). Unfortunately, it is not
implemented recursively for .pro with TEMPLATE=subdir.
You should also look at the QMAKEFEATURES env. variable, very useful for
system wide configuration. If your .pro file contains xxx in CONFIG,
qmake search for a file xxx.prf in QMAKEFEATURES path and includes it.
For example, I use:
CONFIG += cg
so it is included in my source control system and does not have to
change with computers. And on each of my linux/windoes boxes, I have
various (not source controlled) cg.prg files that looks like:
LIBS *= -lCg -lCgGL
> Nathan
>
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
>
--
[ signature omitted ]
Message 6 in thread
Xavier Décoret wrote:
> There is a make dist target that does some job (packing all files used
> by the project and some .prf files). Unfortunately, it is not
> implemented recursively for .pro with TEMPLATE=subdir.
I have Googled but can only find that there is a DISTFILES variable, and the
qmake manual has one paragraph about it that doesn't help me out very much.
Where are you getting the information?
Nathan
--
[ signature omitted ]
Message 7 in thread
Nathan Carter a écrit :
> Xavier Décoret wrote:
>
>
>> There is a make dist target that does some job (packing all files used
>> by the project and some .prf files). Unfortunately, it is not
>> implemented recursively for .pro with TEMPLATE=subdir.
>>
>
> I have Googled but can only find that there is a DISTFILES variable, and the
> qmake manual has one paragraph about it that doesn't help me out very much.
> Where are you getting the information?
>
I discovered it by chande, typing make dist in one of my projects! I do
not know more about this. The qmake doc is quite poored (compared to the
remainder of the Qt doc, of course!). Things like CONFIG +=
debug_release_target, CONFIG *= ordered, etc. are note easy to find
out. I do not know much more...
> Nathan
>
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
>
>
--
[ signature omitted ]
Message 8 in thread
If you used opensource Qt, do you need a Qt license to sell your
software (or embedded device) using Qt?
Thank you
Gert
--
[ signature omitted ]
Message 9 in thread
On Friday 04 August 2006 06:54, Gert Muller wrote:
> If you used opensource Qt, do you need a Qt license to sell your
> software (or embedded device) using Qt?
If you use the Opesource Qt, you must distribute your source code. If you
want to keep your source code private (proprietary) you must pay for a
license. Simple as that. Whether or not your charge for the box your
software comes in, or charge for support, etc, is outside the scope of the
license.
Read more here: http://www.trolltech.com/developer/faqs/Licensing
j
--
[ signature omitted ]
Message 10 in thread
Gert Muller wrote:
> If you used opensource Qt, do you need a Qt license to sell your
> software (or embedded device) using Qt?
Actually you would have needed it even BEFORE, when you developed your
app! ;) That's what the Qt license states...
In other words: you can't hire 99 programmers using the GPL-ed Qt,
because "Hey, we are developing OpenSource software under GPL, too!" and
then all of a sudden switch back to a closed source software, buy one Qt
commercial license and start selling it (to be honest, if you're really
in that case, I don't know what you would do... maybe contacting
Trolltech and pay for the used licenses that you have used so far?)
IF on the other hand your application STAYS GPL-ed I believe you can
sell it! The GPL allows you to charge money for it - even though you
have to give the source code for it.
On the other hand maybe the Qt license "overrides" the GPL in this point
("taking money for it" - because then it's considered commercial and
according to the Qt license you need a commercial Qt license FOR
DEVELOPMENT). I guess certainly in the eyes of Trolltech it does and
this has been discussed several times on this list - I'm not a lawyer so
don't take my words as reference please ;)
Cheers, Oliver
--
[ signature omitted ]
Message 11 in thread
On Thu, Aug 03, Nathan Carter wrote:
>
> Dear List,
>
> I find myself often making zips of my projects by hand in order to move them
> over to another machine for testing and building releases. (Theoretically
> this could best be done via CVS/subversion, but I don't do that yet.) What
I also use rsync for this, which has the advantage that it quite easy to
omit stuff like binaries or CVS control files.
Best,
Uwe Drechsel
--
[ signature omitted ]
