After it took me a little more time than I expected to build GrandOrgue, I have added a few lines to the README file that might help a future developer attempting the same.
I have attached the modified README here ...
diff --git a/README b/READMEindex 74a7548..8bddfe1 100644--- a/README+++ b/README@@ -20,7 +20,7 @@ As a prerequisite, you need to install CMAKE (http://www.cmake.org)and NSIS (htt
#2: TDM64 environment
Install TDM64 from http://tdm-gcc.tdragon.net/download
- Install wxWidgets-2.8.12 from http://www.wxwidgets.org/downloads/ in C:\TDM\wx32\wxWidgets-2.8.12 and C:\TDM\wx64\wxWidgets-2.8.12+ Install the sources of wxWidgets-2.8.12 from http://www.wxwidgets.org/downloads/ in C:\TDM\wx32\wxWidgets-2.8.12 and C:\TDM\wx64\wxWidgets-2.8.12 (same sources at both places)
Install all the tools for translation and help generation (see Building the help and translations on Windows in README C) ). It is a good idea to copy all exe in the same directory and to add this directory to the Windows path (e.g. C:\TDM\tools\bin, C:\TDM\docbook-xsl-1.76.1 )
Building for 32 bits
@@ -29,6 +29,7 @@ As a prerequisite, you need to install CMAKE (http://www.cmake.org)and NSIS (htt
mingw32-make -f makefile.gcc UNICODE=1 BUILD=Release SHARED=0 CXXFLAGS="-m32" CFLAGS="-m32"
GO:
create a build directory (e.g. c:\go\build32)
+ ASIO support: Either add -DRTAUDIO_USE_ASIO=OFF to the cmake parameters below (no ASIO support), or copy the sources from ASIO SDK at http://www.steinberg.net/en/company/developer.html into C:\go\ext\rt\asio\include (the SDK is free but you will need to set up a developer account with Steinberg).
you need to replace %1 by GO revision number at the end of the following line, or copy this line in a bat file and use the revision number as the parameter when executing the bat file.
cmake .. -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE=Release -DUNICODE=1 -DSTATIC=1 -DwxWidgets_ROOT_DIR=C:\TDM\wx32\wxWidgets-2.8.12 -DCMAKE_EXE_LINKER_FLAGS="-m32 -static-libgcc" -DCMAKE_CXX_FLAGS="-m32" -DCMAKE_C_FLAGS="-m32" -DCMAKE_RC_FLAGS="-F pe-i386 -U WIN64" -DDOCBOOK_DIR=C:\TDM\docbook-xsl-1.76.1 -DRTAUDIO_USE_WASAPI=ON -DRTAUDIO_USE_JACK=OFF -DRTMIDI_USE_JACK=OFF -DINSTALL_DEMO=ON -DVERSION_REVISION=%1
mingw32-make
@@ -44,6 +45,7 @@ As a prerequisite, you need to install CMAKE (http://www.cmake.org)and NSIS (htt
mingw32-make -f makefile.gcc BUILD=Release UNICODE=1 SHARED=0 CXXFLAGS=-DHAVE_VARIADIC_MACROS=1
GO:
create a build directory (e.g. c:\go\build64)
+ ASIO support: Either add -DRTAUDIO_USE_ASIO=OFF to the cmake parameters below (no ASIO support), or copy the sources from ASIO SDK at http://www.steinberg.net/en/company/developer.html into C:\go\ext\rt\asio\include (the SDK is free but you will need to set up a developer account with Steinberg).
you need to have build the 32 bit version first since the executables are required to compile the 64 bit version
you need to replace %1 by GO revision number at the end of the following line, or copy this line in a bat file and use the revision number as the parameter when executing the bat file.
cmake .. -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE=Release -DUNICODE=1 -DSTATIC=1 -DwxWidgets_ROOT_DIR=C:\TDM\wx64\wxWidgets-2.8.12 -DCMAKE_EXE_LINKER_FLAGS="-static-libgcc" -DIMPORT_EXECUTABLES=c:\go\build32\ImportExecutables.cmake -DCMAKE_SYSTEM_NAME=Windows -DDOCBOOK_DIR=C:\TDM\docbook-xsl-1.76.1 -DRTAUDIO_USE_WASAPI=ON -DINSTALL_DEMO=ON -DRTAUDIO_USE_JACK=OFF -DRTMIDI_USE_JACK=OFF -DVERSION_REVISION=%1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Install all the tools for translation and help generation (see Building the help and translations on Windows in README C) ). It is a good idea to copy all exe in the same directory and to add this directory to the Windows path (e.g. C:\TDM\tools\bin, C:\TDM\docbook-xsl-1.76.1 )
Optional: Install all the tools for translation and help generation (see Building the help and translations on Windows in README C) ). It is a good idea to copy all exe in the same directory and to add this directory to the Windows path (e.g. C:\TDM\tools\bin, C:\TDM\docbook-xsl-1.76.1)
~~~~~~
The help contains valueable information (eg. ODF reference), therefore I personally would not preferre to promote building without it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
a) Ad touch vs. "make clean" - fine with me (getting builds to work is always a hassle ... so one tries "magic" sometimes, but one shouldn't ... sometimes we believe it saves time).
b) Re 100000 lines: A build for a supporting(!) software that emits output on such a fine granular level is actually almost buggy - that verbosity level is actually only there for debugging nasty build problems, and the writers of that build should have decreased the verbosity to a normal level (like e.g. GO's makefiles) when the build worked. Therefore, if such a cacophony of log message starts to get emitted, one is led to believe that something is quite wrong. The warning should essentially say "dont worry, someone was not thoughtful enough to select the right level of verbosity." (These 100000 lines also maybe decreases performance, as we found out in large builds ourselves ... "console error" is usually a slow and synchronous device...)
c) Re the help: In my case, I did not want to "pollute" my machine with the many tools necessary for building. But I know that I will only fix as few bugs as possible (hoping there are almost none; and that you, the developer(s), will be faster fixing them than I can find them :-) ); so the documentation from the last public build is sufficient for me - and it might also be for other "low key code providers" like me. But of course, everyone can find out like me that this is supported anyway.
So, summarizing:
a) I'm with you.
b) I'd like to see a hint about that non-standard behavior.
c) I'm more or less with you.
Regards
Harald
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
add a) So a windows user should verify, that "mingw32-make -f makefile.gcc clean" works.
add b) Redirecting stderr to /dev/null is a very bad idea, as it will also redirect all error messages to /dev/null.
Fixing warnings in the "supporting" software wxWidgets is not the scope of this project - if the upstream project would release a fixed version, we will pick it up [I doubt, that it does this, as 3.0 has been released].
... prio needn't be 1 on this one - forgot to move it down somewhat.
Milestone is also wrong (...Documentation). Sorry.
Last edit: Harald M. Mueller 2014-04-25
Acceptable part:
~~~~~~
The help contains valueable information (eg. ODF reference), therefore I personally would not preferre to promote building without it.
a) Ad touch vs. "make clean" - fine with me (getting builds to work is always a hassle ... so one tries "magic" sometimes, but one shouldn't ... sometimes we believe it saves time).
b) Re 100000 lines: A build for a supporting(!) software that emits output on such a fine granular level is actually almost buggy - that verbosity level is actually only there for debugging nasty build problems, and the writers of that build should have decreased the verbosity to a normal level (like e.g. GO's makefiles) when the build worked. Therefore, if such a cacophony of log message starts to get emitted, one is led to believe that something is quite wrong. The warning should essentially say "dont worry, someone was not thoughtful enough to select the right level of verbosity." (These 100000 lines also maybe decreases performance, as we found out in large builds ourselves ... "console error" is usually a slow and synchronous device...)
c) Re the help: In my case, I did not want to "pollute" my machine with the many tools necessary for building. But I know that I will only fix as few bugs as possible (hoping there are almost none; and that you, the developer(s), will be faster fixing them than I can find them :-) ); so the documentation from the last public build is sufficient for me - and it might also be for other "low key code providers" like me. But of course, everyone can find out like me that this is supported anyway.
So, summarizing:
a) I'm with you.
b) I'd like to see a hint about that non-standard behavior.
c) I'm more or less with you.
Regards
Harald
add a) So a windows user should verify, that "mingw32-make -f makefile.gcc clean" works.
add b) Redirecting stderr to /dev/null is a very bad idea, as it will also redirect all error messages to /dev/null.
Fixing warnings in the "supporting" software wxWidgets is not the scope of this project - if the upstream project would release a fixed version, we will pick it up [I doubt, that it does this, as 3.0 has been released].
If the warnings are really such a big issue for you, pass different compiler options (via CFLAGS and CXXFLAGS):
http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
From my point of view, a verbose build is better - getting a copy of a full build output allows better remote support.
Console "devices" have turned into a computer program, which display the text in a GUI - CPUs and GPUs are getting faster, so drawing the log messages should not be a issue today.
(On OBS, the build with verbose output took about 6 minutes: https://build.opensuse.org/build/home:e9925248:mingw/openSUSE_12.3/x86_64/mingw64-wxwidgets/_log )
add c) You need gettext, if you want a translated version and/or add missing translations.