[wxCode-users] Re: Building wxCode components

[Mike W. <mik...@nt...>]

On Thursday 25 March 2004 4:54 pm, Otto Wyss wrote:
> Code submitted to wxCode has a problem when build and linking with
> wxWidgets. Relative path can't be used. Therefore I suggest the use
> of environment variables for this:
>
> - $(WXSTABLE): Points to the stable released wxWidgets directory
> (currently 2.4.2)
> - $(WXTEST): Points to the devel released wxWidgets directory
> (currently 2.5.1)
> - $(WXDEVEL): Points to the devel wxWidgets directory (CVS HEAD)
>
> If we can agree on the names of these variables I suggest that anyone
> starts using them. I also suggest that any code within wxWidgets
> which doesn't belong to the core starts using them as well. This
> mostly involves any code in contrib, sample, utils, etc.
>
> Standardizing on environment variables means code can much easier be
> moved from one place to the other.

Hi Otto,

As I understand it, the current idea is for 
wxWidgets/contrib/components to be a link to wxCode/components. 
However, like you say, that means that reverse relative paths don't 
work.

So what I'd suggest is that, instead of using these environment 
variables, the components be put directly into the wxWidgets tree 
rather than linked.

So for example, a CVS user would checkout wxCode then move the 
'components' subdirectly into wxWidgets/contrib. I believe that cvs 
would still work correctly for the moved components subdirectory, and 
also when using cvs for wxWidgets, it would ignore the wxCode stuff.

The reason I suggest this is that:
1. wxWidgets' bakefiles can be run 'as is' to generate makefiles for 
wxCode if we do this.
2. Not all filesystem have links.
3. Not all make programs support variables (though I guess those ones 
could be avoided).

Another suggestion, is that instead of installing the components under 
wxWidgets/contrib/components, how about installing them in 
wxWidgets/wxcode, just to make the paths a bit shorter. Or would the 
renaming be confusing? The only change that's need to make that work 
with wxWidgets' bulid system is a small change to configure.in, so I 
could ask if this would be acceptable on wx-dev.

Anyway, I've tried both these idea out, so they work ok.

What do you think?
Mike