Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

wx_cfg custom variable

<< < (2/4) > >>

takeshimiya:
Yes you can, but not using more than one macro in the same line.

thomas:

--- Quote from: grv575 on December 21, 2005, 01:30:06 am ---1.  it should be WX_SUFFIX=u and not $WX_SUFFIX=u (latter didn't compile correctly for me)
--- End quote ---
Right, and this is why macro expansion was/is broken at all.
I spent 2 days searching what was wrong when in fact, nothing was wrong, only MacrosManager was given $VARIABLE instead of VARIABLE as name. I thought that this was only what is shown in the dialog, but the variable name is actaully changed. And you seem to have no way to do differently. If you delete the '$', it is added back when you close the dialog!
Unluckily, I could not find where the '$' is being added, so I finally did this before adding names to MacrosMap:
if(key[0] == _T('$'));
  key = key.Mid(1);
and it seemed to work immediately. My test project went ok, and even Code::Blocks (as the ultimate test) compiled fine. However, the problem you are having now seems to come exactly from these two lines. If I comment them out, that problem is gone (but the first problem is back).
Yiannis is doing a compiler overhaul today, so the build calculations are not all done before the build starts. In this course, he will look into the variable issue too, as variables are being initialised and replaced at different times anyway.


--- Quote from: grv575 on December 21, 2005, 01:05:08 am ---wx_cfg is missing in the latest build (1578).  Is this intentional.  I would think that it should be kept since this allows you to have different wx/setup.h files for unicode/nonunicode.
2.  WX_CFG=Unicode is still needed to use the Directories settings as is:
--- End quote ---
Not intentional, and yes it is... I don't see a use for it really.
What you describe is exactly what WX_SUFFIX does (if it works). Your setup.h is located either in msw or in mswu.
WX_CFG was used in a strange, unhealthy way, giving you a path like lib/gcc_dllUnicode/msw when it really should just be lib/gcc_dll/mswu.  At least in my setup it always did... your mileage may vary.
But hey, if you absolutely need WX_CFG, there is no reason against it :)

David Perfors:
In the case of unicode or ansi build WX_CFG is not needed.. But when you have more than one configurations of wxWidgets (example one for Code::Blocks and one for my own program) than it is usefull to use. But it is not an required, although a standard CFG of cb is nice to have ;)

thomas:
I am thinking about an entirely different thing at the present time. I plan to extend global user variables by adding more members and implementing profiles (let's rather call these "sets", so we don't confuse them with Code::Blocks profiles).

Right now, within one profile, you have a couple of global user variables, like for example $(#wx) and $(#gcc). The idea of global user variables is to make your life easier because you do not need to redefine the same stuff again and again.
But how does reality look like? You want to build one project in ANSI and in Unicode (and maybe with two different versions of wx, too), and despite global user variables, it still sucks. You still have to do a lot of stupid editing every time because you need an extra path, an extra compiler switch, a suffix, a different value for WX_CONF, whatever.
You could start Code::Blocks with different profiles and have your global variables defined differently in every profile. While this works, it just is not practicable. It sucks.

Enter global user variable sets. The idea is not to define one global user variable, but an entire set of them, and only switch the set to compile in Unicode instead of ANSI. If a variable is not defined in the current set, the one in the "default set" is used instead. This way, the config file stays backwards compatible, and you can mix and match to a certain extent.

The most difficult part about this is of course (as always) how to desing a user interface for that  :(

takeshimiya:
I noticed that problem long ago, so I agree that global variables needs a revision.

Because now, it assumes everything is a C++ project (predefining the /lib, /include).
It should be more flexible.

Navigation

[0] Message Index

[#] Next page

[*] Previous page