SpellChecker_wx31 cbp bug ?

[gd_on]

In SpellChecker_wx31*.cbp, svn 11488, this line (n° 63) :

Code: [Select]

<Variable name="WX_VERSION" value="28" />
is probably wrong. It should be value="31".
Nevertheless, compilation works as expected, so may be this line is not used.
gd_on

[ollydbg]

Nevertheless, compilation works as expected, so may be this line is not used.

This is interesting, which version of C::B do you use to build C::B?

See some discussion here:Code::Blocks / Tickets / #744 Can't compile SpellChecker plugin on MSW and WX31

[gd_on]

When I compiled svn 11488, my operationnal C::B version was 11482.
May be the reason why it worked is not there.
My usual compiler is TDM 4.9.2 because gfortran 5.1 does not work as expected (32 or 64 bits, respectively in C:\MinGW32 and C:\MinGW64). I tried also a standard 8.1 version (posix, seh for 64 bits and posix, sjlj for 32 bits), but only for tests until now.
In my MinGW64\bin  folder I have both wxmsw28u_gcc_cb_64.dll and wxmsw311u_gcc_cb_64.dll because I have some "old" wxwidgets executables still working with wxwidgets 2.8.12 64 bits.
In my MinGW32\bin  folder I have both wxmsw28u_gcc_cb.dll and wxmsw311u_gcc_cb.dll because I have some "old" wxwidgets executables still working with wxwidgets 2.8.12 32 bits.
I have also a C:\wxWidgets-2.8.12 folder where wxWidgets 2.8 was built.
C::B itself is linked with wxWidgets 3.1.1 64 bits.
So may be, when I build C::B, spellchecker finds a 2.8 library at compile time and use it. Strange indeed ! I must certainly switch completely to wxWidgets 3.1.1 and forget 2.8.12 version, but I have still some work before switching.
gd_on

[Miguel Gimenez]

Ticket 744 was closed, but it is not completely fixed. Revision 11488 fixed the wx28 projects, but the wx30 projects must be also fixed and the changes to wx31 projects were flawed, using 28 instead of 31 (as gd_on noted). In that ticket I attached a patch that wasn't used.

[ollydbg]

Here is the build log of rev11488 of spell check 32bit wx31 project(SpellChecker_wx31.cbp).

About the linker option, only the last target is need the linking option "-lwxmsw31u", the other targets do not need this linker options, so WX_VERSION is only used in the last target. The other targets are just using the ar.exe to achieve the object files.

About the compiler option when building the first target named "hunspell"

Code: [Select]

[  5.0%] g++.exe -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DwxUSE_UNICODE -std=gnu++11 -g -O0 -pipe -mthreads -fmessage-length=0 -fexceptions -DHUNSPELL_STATIC -Iwxspellchecker\include -IE:\wxWidgets-3.1.1-rc\include -IE:\wxWidgets-3.1.1-rc\lib\gcc_dll\mswu -Ihunspell\src\hunspell -Ihunspell\ -c hunspell\src\hunspell\affentry.cxx -o ..\..\..\.objs31\plugins\contrib\SpellChecker\hunspell\hunspell\src\hunspell\affentry.o
I see in the target's compiler option, there is a line:

Code: [Select]

$(#WX31.lib)\gcc_dll$(WX_CFG)\msw$(WX_SUFFIX)
But the WX_CFG and WX_SUFFIX is not defined in the target level. I also don't find those variables in project level.
So, how does those custom variables expand? Maybe, I just build the CodeBlocks_wx31.cbp, and the custom variables are cached?

[ollydbg]

I just testing building SpellChecker wx3.1.x under C::B(rev11488), and here is the log(see attachment file):

Code: [Select]

-------------- Build: hunspell in SpellChecker wx3.1.x (compiler: GNU GCC Compiler)---------------

g++.exe -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DwxUSE_UNICODE -std=gnu++11 -g -pipe -mthreads -fmessage-length=0 -fexceptions -DHUNSPELL_STATIC -DTEST -Iwxspellchecker\include -IE:\wxWidgets-3.1.1-rc\include -IE:\wxWidgets-3.1.1-rc\lib\gcc_dll\msw -Ihunspell\src\hunspell -Ihunspell\ -c D:\code\cb\cb_sf_git\clean-trunk-for-commit\src\plugins\contrib\SpellChecker\hunspell\src\hunspell\affentry.cxx -o ..\..\..\.objs31\plugins\contrib\SpellChecker\hunspell\hunspell\src\hunspell\affentry.o

You see, the path is

Code: [Select]

-IE:\wxWidgets-3.1.1-rc\lib\gcc_dll\mswAnd you can see the "u" is missing compared with the build log I build SpellChecker wx3.1.x under C::B(rev11210).

Maybe, this commit cause the difference:

Code: [Select]

Revision: 1ce96228a102fb0e2acc587d1984ee2a3039ac59
Author: fuscated <[email protected]>
Date: 2018/9/12 6:38:32
Message:
* compiler: Clear target specific variables from the MacroManager on every recalculation (ticket #582, thanks bluehazzard)

> The problem with the old version is that if a certain variable is defined
  only in one target (A) and not in the others. If the target A is built
  first the variable will be stored in the marco manager and then the
  variable will be available for the other targets.
> This is probably incorrect and unwanted. I'm sure we'll break someones
  build, but probably this hopefully would find an error in their setup.
> To reproduce the problem try the following:
  1. Create a project with 3 targets (A, B, C).
  2. Add them to a virtual target. Beware of order.
  3. Add the same variable to targets A and B. Make sure target B doesn't
     define the variable
  4. Add a define like MYVAR=$(VAR) to the project options.
  5. Rebuild the virtual target.
  6. Inspect the build log. You should see that for target B there is
     something like -DMYVAR= so the $(VAR) should be expanded to empty
     string.
> Note: This is surely not the most efficient solution. But the marco
        manager needs a revision anyway to improve build performance.
> Note: Build regressions due to inefficiencies are most visible in clean
        builds.

git-svn-id: https://svn.code.sf.net/p/codeblocks/code/[email protected] 2a5c6006-c6dd-42ca-98ab-0921f2732cef




[Miguel Gimenez]

The wxSpellChecker target needed WX_SUFFIX to be defined in order to find the wx/setup.h when compiling (not related to linking)
 
I think you are right, that commit broke the build of the target because the project's configuration was flawed beforehand.

EDIT: mortenmcfly fixed the CBP some minutes ago and closed ticket 744 again.

[gd_on]

Better with svn 11494.
Nevertheless, as mentioned by ollydbg, there is still an incorrect include for the target hunspell :

Code: [Select]

-IC:\wxWidgets-3.1.1\lib\gcc_dll\msw which does not exist.
It should be -IC:\wxWidgets-3.1.1\lib\gcc_dll\mswu. Other targets have the right include.
If it works, it's probably because this include folder is not necessary.
gd_on

[ollydbg]

...
If it works, it's probably because this include folder is not necessary.

Hi, gd_on, thanks for the test.
I'm agree with you, here is patch which I remove the unnecessary compiler search paths from the first build target, can you give a try? It works fine here.

Code: [Select]

-------------- Build: hunspell in SpellChecker wx3.1.x (compiler: GNU GCC Compiler)---------------

g++.exe -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DwxUSE_UNICODE -std=gnu++11 -g -pipe -mthreads -fmessage-length=0 -fexceptions -DHUNSPELL_STATIC -DTEST -Ihunspell\src\hunspell -Ihunspell\ -c D:\code\cb\cb_sf_git\clean-trunk-for-commit\src\plugins\contrib\SpellChecker\hunspell\src\hunspell\affentry.cxx -o ..\..\..\.objs31\plugins\contrib\SpellChecker\hunspell\hunspell\src\hunspell\affentry.o
...
BTW: some macro definition like "__WXMSW__" is defined in the project level, and in-fact, they are not needed here to build the hunspell target. But my patch doesn't remove those macro definitions.

Code: [Select]

src/plugins/contrib/SpellChecker/SpellChecker_wx31.cbp | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/src/plugins/contrib/SpellChecker/SpellChecker_wx31.cbp b/src/plugins/contrib/SpellChecker/SpellChecker_wx31.cbp
index f449ffde..8c34f248 100644
--- a/src/plugins/contrib/SpellChecker/SpellChecker_wx31.cbp
+++ b/src/plugins/contrib/SpellChecker/SpellChecker_wx31.cbp
@@ -21,9 +21,6 @@
  <Add option="-fmessage-length=0" />
  <Add option="-fexceptions" />
  <Add option="-DHUNSPELL_STATIC" />
- <Add directory="wxspellchecker/include" />
- <Add directory="$(#WX31.include)" />
- <Add directory="$(#WX31.lib)/gcc_dll$(WX_CFG)/msw$(WX_SUFFIX)" />
  <Add directory="hunspell/src/hunspell" />
  <Add directory="hunspell/" />
  </Compiler>


The wxSpellChecker target needed WX_SUFFIX to be defined in order to find the wx/setup.h when compiling (not related to linking)
 
I think you are right, that commit broke the build of the target because the project's configuration was flawed beforehand.

EDIT: mortenmcfly fixed the CBP some minutes ago and closed ticket 744 again.

Yes, I agree with you. wxSpellChecker is the second build targets which does need wx header files. OBF's commit rev11465 just clear all the previous targets custom variables' value when building a new targets, so all the cached values are cleaned.
I'm going to commit the above patch to make things more clean.

[ollydbg]

A patch which further clean up the Windows cbps, I remove the unnecessary wx related compiler and linker search options, any comments? I only test the 32bit wx31 build.

[ollydbg]

A patch which further clean up the Windows cbps, I remove the unnecessary wx related compiler and linker search options, any comments? I only test the 32bit wx31 build.

In svn trunk now.