Re: [XBoard-devel] config.h problem

[Tim Mann]

The xboard makefiles can compile xboard in a subdirectory, and I always
do it that way.  Example of doing this for the first time:

cd ..../xboard
mkdir linux-x64
cd linux-x64
../configure
make

Then you don't end up with a config.h in the xboard directory.  It's
also handy if you want to compile for more than one platform from the
same sources -- say 32-bit and 64-bit x86 Linux, but in the past I
compiled for more platforms than that.

Of course other people who download the sources won't necessarily know
they should do that.  In the short term (2) seems okay to help avoid
that pitfall, but if the person really is building xboard in the parent
directory too, (2) will break his xboard build until he regenerates
config.h.

Possibly in the longer term it would be good to reorganize the sources
so that you can't build xboard in the parent directory of winboard.
Maybe move the xboard-only sources (and the common sources too?) to
subdirectories alongside winboard.  Make sure the xboard makefiles can
still compile in a subdirectory of xboard (or a directory alongside
it?) so that you can still compile for multiple platforms.  Does git
let you rename files within a project without messing up the version
history?

Historical note: the windows config.h was never automatically
generated.  Not sure this is still true now, but originally Windows was
pretty much a constant, so there was no point in having a configure
script go out and discover things to generate a config.h.

        --Tim

On Sun, 12 Jul 2009 09:41:57 -0600, Eric Mullins <address@hidden> wrote:
> In order to build winboard properly, we must #include the correct 
> config.h file from the winboard directory.
> 
> If this file happens to be present in the xboard directory, all the 
> cmdline compilers I'm testing will #include the wrong one.  I suspect 
> the GUI ones won't suffer from this problem, but I'm not sure yet.  This 
> problem affects devs more than regular users, since we are more likely 
> to actually have config.h in the xboard directory.
> 
> So what do we do?
> 
> 1) nothing.  Assume the devs are smart enough to just delete the 
> config.h from the xboard directory when this happens.  When we package 
> the source, there shouldn't be a config.h in the xboard directory 
> anyway, so end users trying to compile winboard should never get this 
> problem.
> 
> 2) update the GCC and MS makefiles to remove ..\config.h.  I don't see 
> any immediate downside to this, but it seems kludgy.
> 
> 3) rename winboard/config.h to something else.  I'm not sure what 
> ramifications this might have.  All the files in the xboard directory 
> that we need actually do need winboard/config.h.  The problem is that 
> config.h in the xboard dir is automatically generated, while the one in 
> the winboard directory isn't.  Maybe it used to be at one point, but it 
> became a sort of bastardized version of config.h specific to windows.  
> Unfortunately, it's the one we actually need right now.
> 
> 4) other ideas?
> 
> 


-- 
Tim Mann  address@hidden  http://tim-mann.org/