qBittorrent project needs help on Windows front

[Dayman]

[quote="bfelten"]
But don't try to add all four commands into a single batch file, after the second command (starting another batchfile) has ended, the entire process ends, and it'll never come to the two nmake commands.
[/quote]
Executing another batchfile from a batchfile is done with CALL command, otherwise control will be passed to the second batchfile and the first one will be discarded.

---

P.S. Anyone interested in contributing code through GitHub on windows should probably read this: https://help.github.com/articles/dealin ... rm-windows

[bfelten]

For those interested in making things a little more easy, here's the batch file I ended up with -- now working properly. Just name it e.g. 'mk.bat', place in the openssl directory and run it. No directory names or anything should need to be changed. But you must of course run it from an MSVC2008 command shell:

Code: Select all

for /f "tokens=* delims=/" %%A in ('cd') do set CURRENT_DIR=%%A
perl Configure VC-WIN32 no-shared no-zlib-dynamic threads --prefix="%CURRENT_DIR%\my_build"
call ms\do_nasm
nmake -f ms\nt.mak
nmake -f ms\nt.mak install
xcopy my_build\include\*.* "%VCINSTALLDIR%\include\" /Y /Q /S
xcopy my_build\lib\*.* "%VCINSTALLDIR%\lib\" /Y /Q /S

[bfelten]

[quote="Dayman"]Executing another batchfile from a batchfile is done with CALL command, otherwise control will be passed to the second batchfile and the first one will be discarded.[/quote]

Of course. What I missed was that ms\do_nasm actually was a batchfile.

[bfelten]

OK, so I've made a lot of changes -- or rather additions -- to the wiki. If you think I'm way out of line there, feel free to tell me off.

I regard myself as something of a batch file guru, and just love to contribute even with such small stuff. But that's probably just my ego talking... 

[bfelten]

After all those efforts, I still can't get the damn thing to compile. I don't know if the 'misc::toQString' error I reported previously -- still remaining no matter what I do -- is just the tip of an iceberg, or just a single error.

Is there actually anyone here, who's managed to compile it all from scratch, just following the wiki?

[Dayman]

I thinks it needs Qt built with -stl option.

P.S. I may end up uploaded my build scripts someday. They are for 64-bit builds though.

[bfelten]

[quote="Dayman"]They are for 64-bit builds though.[/quote]
Looking forward to that -- that's what I really wanted in the first place any way. Building 32-bit apps is so 00-ish. Just as 8-bit apps are 1980-ish and 16-bit apps are 1990-ish  -- welcome to the 202:nd decade, we're almost three years into it now... 

[sledgehammer_999]

@bfelten
Yes, nice just the batch approach, but I want to keep it as an optional step. That's why I reverted some of your wiki changes and I put the optional tag.
I see that you are having problems compiling qbt. Do the problems still occur? If yes, can you post some more info about what the error is?
Also, please for the first time follow the wiki instructions AS IS, without doing any modification or trying to use batch files. This is to verify that the instructions work on your machine. After that you can experiment with other options or batch files to automate the process.

@Dayman
If you want to post your instructions on how to build a 64bit version please create a new page here with the appropriate name. If however, your method doesn't diverge much from the official method then feel free to edit the "official method" wiki page.

About the 32bit vs 64bit: First of all utorrent doesn't seem to provide different versions either. Secondly, I don't believe that 64bits offer a significant(if any) boost in performance. A bittorrent client doesn't do much CPU intensive tasks to really benefit from 64bit.(I may be wrong though. I don't have any test data on that). On the other hand, 64bit slightly increase the memory footprint of the program. Lastly, other everyday apps are 32bit only, eg Firefox, so in the end 32bit isn't that uncommon.

We could try a different approach though. I could switch to gcc builds(it is feasible-> link) and cross build the 64bit from a 32bit host. Another solution is for Dayman,bfelten (or anyone else who is up to the task) to be the "Windows 64bit packager". Of course, we will need to get permission from Chris, to upload on sf.net. But this is the least of our worries.

[loki]

I think I chimed in on this "fight" about a pointless 64-bit version once too. One of the main reasons I know of to have a 64-bit program is to allow it access to larger amount of RAM, unnecessary in a torrent program... I sure wouldn't use a torrent program either if it needed to address more than 3-4GB of RAM.
Faster? Not specifically. More efficient? Maybe, but is negligible at best.
One theory which might hold true, possibly one advantage, creating (large) torrent file... though this is probably commonly bottle-necked by the HDD and not processor anyway.
Processors and OS's we have are backwards compatible to 32-bit programs also... so is not "necessary" as it may be with linux package-wise.

[Dayman]

[quote="sledgehammer_999"]
@Dayman
If you want to post your instructions on how to build a 64bit version please create a new page here with the appropriate name. If however, your method doesn't diverge much from the official method then feel free to edit the "official method" wiki page.
[/quote]
It differs mostly in using layout=system for boost (and boost=system for LT) and using make install wherever possible.
Btw, copying anything into system include and lib dirs on windows is a bad idea. You can use these bjam options when building LT: "include=%BUILDROOT%\OpenSSL\OpenSSL64\include" "library-path=%BUILDROOT%\OpenSSL\OpenSSL64\lib"
[quote="sledgehammer_999"]
Secondly, I don't believe that 64bits offer a significant(if any) boost in performance. A bittorrent client doesn't do much CPU intensive tasks to really benefit from 64bit.(I may be wrong though. I don't have any test data on that). On the other hand, 64bit slightly increase the memory footprint of the program.
[/quote]
I agree on performance: speed boost in very small for not cpu intensive tasks, if there is at all. Still i686 arch is way outdated, x86_64 has way more registers, which is really good for compiler optimizations.
[quote="sledgehammer_999"]
Lastly, other everyday apps are 32bit only, eg Firefox, so in the end 32bit isn't that uncommon.
[/quote]
Waterfox, Palemoon, Firefox Nightly (before they dropped 64-bit builds in 17.0) There is a bunch of other 64-bit applications.

[sledgehammer_999]

[quote="Dayman"]
[quote="sledgehammer_999"]
@Dayman
If you want to post your instructions on how to build a 64bit version please create a new page here with the appropriate name. If however, your method doesn't diverge much from the official method then feel free to edit the "official method" wiki page.
[/quote]
It differs mostly in using layout=system for boost (and boost=system for LT) and using make install wherever possible.
Btw, copying anything into system include and lib dirs on windows is a bad idea. You can use these bjam options when building LT: "include=%BUILDROOT%\OpenSSL\OpenSSL64\include" "library-path=%BUILDROOT%\OpenSSL\OpenSSL64\lib"[/quote]

I think you should create a separate page(copying whatever you need from the other pages), for the sole reason of having a tested official "working" guide and not confuse possible contibutors.

For the system include/lib you are right. I didn't like it either but I needed a quick way to solve potential pitfalls. eg How do you direct qt's configure.exe to look for your openssl include/lib ?

[quote="Dayman"][quote="sledgehammer_999"]
Secondly, I don't believe that 64bits offer a significant(if any) boost in performance. A bittorrent client doesn't do much CPU intensive tasks to really benefit from 64bit.(I may be wrong though. I don't have any test data on that). On the other hand, 64bit slightly increase the memory footprint of the program.
[/quote]
I agree on performance: speed boost in very small for not cpu intensive tasks, if there is at all. Still i686 arch is way outdated, x86_64 has way more registers, which is really good for compiler optimizations.
[quote="sledgehammer_999"]
Lastly, other everyday apps are 32bit only, eg Firefox, so in the end 32bit isn't that uncommon.
[/quote]
Waterfox, Palemoon, Firefox Nightly (before they dropped 64-bit builds in 17.0) There is a bunch of other 64-bit applications.
[/quote]

Ok noted. The only think I have to say is that currently qbt really needs(IMO) contributors/bug fixers/programmers more than providing a 64bit build. The bug reports/feature requests are increasing  daily and there isn't enough manpower to resolve them quickly.

[Dayman]

[quote="sledgehammer_999"]

For the system include/lib you are right. I didn't like it either but I needed a quick way to solve potential pitfalls. eg How do you direct qt's configure.exe to look for your openssl include/lib ?[/quote]
configure.exe -I %BUILDROOT%\OpenSSL\OpenSSL64\include -L %BUILDROOT%\OpenSSL\OpenSSL64\lib

[bovirus]

Should be possible to make the languiage file outsuide the core of teh program as standalone file?
In this way should be possible to change/revise the language file without rebuild the exe & installer.
Thanks.

[John Peterson]

It's important that build commands are available because that makes it easy to build to program

[sledgehammer_999]

@John Peterson they are available in the wiki page. link