wx_cfg custom variable

[grv575]

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.

[takeshimiya]

thomas created a CodeBlocks-NewBuild-UNI.cbp for Unicode, altrough in the end will be merged back to one project I think.

I suppose it's because the bug in macros expansion...

[grv575]

I know but it doesn't work

1.  it should be WX_SUFFIX=u and not $WX_SUFFIX=u (latter didn't compile correctly for me)
2.  WX_CFG=Unicode is still needed to use the Directories settings as is:

So the ansi newbuild should have
WX_CFG=NonUnicode
WX_SUFFIX=

the unicode newbuild should have
WX_CFG=Unicode
WX_SUFFIX=u

otherwise it doesn't work the way the directory paths are set in the .cbp

unless of course how this is going to work is being redone...

[takeshimiya]

Yeah, that's all correct, but I suppose it'll be fixed once the macros expansion bug is fixed.

[rickg22]

what bug? Does it mean I can't compile C::B now?

[takeshimiya]

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

[thomas]

1.  it should be WX_SUFFIX=u and not $WX_SUFFIX=u (latter didn't compile correctly for me)

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.

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:

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.

[thomas]

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

That, however, will certainly stay the way it is. First, it makes sense, and second, I cannot change the semantics of these without being burned on the stake, because existing projects rely on this functionality.

[takeshimiya]

I'm not sure about that, this needs to be discussed now that RC3 isn't released yet, so anything can be broken/unbroken in SVN.

I'm not even sure a different syntax for global and non global variables is good.

It would be perhaps better (and more intuitive for new users) to have $(PROJ_VAR), $(GLOBAL_VAR), $(COMPILER_VAR) syntax.

The current solution only saves you to type the /include and /lib only, but it appears to me that causes more harm than it does.

I'd rather would like to be prompted with 3 global vars: $(WX_INCLUDE), $(WX_LIB), and $(WX_PREFFIX).

And on the GUI part: Instead of (as is currently), prompt one dialog after another when Global Variables are used for the first time, show all the new global variables to be entered in a single dialog.

This should be taken seriously IMHO.

[mandrav]

I'm not even sure a different syntax for global and non global variables is good.

Really? Can you come up with an implementation that uses the same syntax for all variables then?
It's nice to talk from a theoretical point of view all the time, but the least you could do is elaborate on what you wrote.
How would you differentiate between normal vars and custom vars, if they all share the same syntax?
And how come that it would be more intuitive to the user? At first glance you can tell a variable is global right now. How would you tell if all variables looked the same?

The current solution only saves you to type the /include and /lib only, but it appears to me that causes more harm than it does.
I'd rather would like to be prompted with 3 global vars: $(WX_INCLUDE), $(WX_LIB), and $(WX_PREFFIX).

Hmm, nice, type in three edit boxes. Do you know of many common libraries that don't use the /lib and /include convention? I don't understand what the gain would be.
And about $(WX_PREFIX) you mentioned, Thomas already posted that some things will be changed in global vars to make them more adaptable.

[thomas]

You might want to read the documentation, too. I spent a good hour writing one, you know. Maybe then you don't want three separate variables any more

[280Z28]

I am pretty happy with the syntax and abilities right now. However, I think the last update that fixed per-target custom variables actually broke things again. It replaces global variables correctly but replaces all per-project and per-target variables with "" (empty).

rev 1578.