problems building w/ cygwin g++

[Steve Black]

I'm still new to SE and I've been acquainted with g++ for all of 24 hours now, so feel free to fit me with a dunce cap if I'm just missing the obvious here, but...

With a new GNU C++ Wizard project, initially set to build with generated makefile:

• Include path set to "C:\..." becomes "/..." in makefile and the included file is not found
• Switching to manual make (with same file) yields "GCCTest.mak:37: *** missing separator (did you mean TAB instead of 8 spaces?).  Stop." where line 37 contains 1 tab and the compile command
• Switching to vsbuild builds successfully, but subsequent builds cannot open the .vbp file and fail
• Manually deleting the .vpb file lets the build run, but results in duplicate definitions, evidently because the prior .o file is still there and is getting linked to itself.
• deleting the .o file (& .vpb) gives good result
• Throughout this I occasionally get warnings (when using makefiles) that there are paths with spaces (true, so they should just get quoted, yes?) that may cause problems.  There are no reported problems, though, that are obviously related to this.

Some of this seems to point to bugs in GNU make (e.g. missing drive letter) but SE could be generating a better makefile, I think.

Can anyone straighten me out here?

[Dennis]

To save yourself a lot of time and headaches, if you plan on building with make, do not put your code or includes in paths containing spaces.  This was a limitation we ran into generating the makefiles.  It may be possible to work around by quoting, and we have open bug reports filed to that effect.

[Steve Black]

Thanks for the tip Dennis.  Unfortunately, the code is where it is and I can't necessarily move it about at will.  I'll look forward to seeing this fixed.  Right now the only way I can build w/ Slick/cygwin is using vsbuild and deleting .vpb and .o files between builds.  Which is pretty close to saying I can't build with Slick/cygwin.  Fortunately I can still use MSVS, but I was really looking forward to moving away from that.

[Dennis]

You are the first to report trouble with the .vpb and .o files.  Is it possible for you to zip up the entire thing and send it into support?  If too much of the project is proprietary, could you create a small sample project that uses vsbuild to build and exhibits the problem and send that into support?

[Steve Black]

Here ya go.

This is just some hacking at a sample that turned out to be the wrong code for the job anyway.  It does build successfully and does still exhibit the behavior.  (I tested just now.)  Also, I did move it to a path without spaces and had the same problem.

Path of files in zip: GCCTest\*
Path of to project: C:\Documents and Settings\My Documents\Development\Projects\
Alternate: C:\Development\Projects\

Here are messages before deleting .vbp and .o

Code: [Select]

C:\Documents and Settings\sblack\My Documents\Development\GCCTest>VSLICKERRORPATH="C:\Documents and Settings\sblack\My Documents\Development\GCCTest"

C:\Documents and Settings\sblack\My Documents\Development\GCCTest>---------- Build Project: 'GCCTest.vpj' - 'Debug' ---------- VSLICKERRORPATH="C:\Documents and Settings\sblack\My Documents\Development\GCCTest"
Cannot open file 'C:\Documents and Settings\sblack\My Documents\Development\GCCTest\Debug\GCCTest.vpb'
*** Errors occurred during this build ***

and after:

Code: [Select]

C:\Documents and Settings\sblack\My Documents\Development\GCCTest>C: & cd "C:\Documents and Settings\sblack\My Documents\Development\GCCTest\"
echo VSLICKERRORPATH="C:\Documents and Settings\sblack\My Documents\Development\GCCTest"

C:\Documents and Settings\sblack\My Documents\Development\GCCTest>VSLICKERRORPATH="C:\Documents and Settings\sblack\My Documents\Development\GCCTest"

C:\Documents and Settings\sblack\My Documents\Development\GCCTest>"C:\Tools\SLICKE~1\win\vsbuild" build "C:\Documents and Settings\sblack\My Documents\Development\GCCTest\GCCTest.vpw" "C:\Documents and Settings\sblack\My Documents\Development\GCCTest\GCCTest.vpj" -signal 9009
---------- Build Project: 'GCCTest.vpj' - 'Debug' ---------- VSLICKERRORPATH="C:\Documents and Settings\sblack\My Documents\Development\GCCTest"
Dependency database not found.  Rebuilding...
GCCTest.cpp
Linking...
Build successful


[Dennis]

The problem is your wildcard specification (*, recursive) which is too general, since it includes also all the files under your "Debug" directory, including the ".vpb" file.  Since the ".o" files were also included in your project, that explains why you were getting linkage errors about multiply defined symbols, because the .o was linked in twice.

Try creating two separate wildcards (*.h, recursive) and (*.cpp, recursive).  This way your project only includes source files, not anything and everything that happens to be in the directory tree.

The alternate approach is to use the wildcard excludes to exclude the problem files.  For example, if you change your wildcard exclude spec to the following (note, no spaces):

Code: [Select]

*.vtg;*.vpj;*.vpw*;*.vpb;*.exe;*.o
Then the ".vpb" file, the ".o" files, and the executable will be excluded from the project and you will be able to build and rebuild without problems.

Generally, I tend to prefer the "everything that belongs" technique over the "everything except this junk" technique.  It's like ordering lunch -- it's much safer to tell the waitress what you want to order than to give her a list of things you do not want and then see what you get.

[Steve Black]

Uh oh.

Well, let me respond in parts:
First, replacing * wildcard with *.c* & *.h* worked while adding *.vpb;*.o;*.exe exlcusion to * wildcard did not work.

Second, I can't really work with any specification other than *.  My definition of a project is not limited to the source files that need to be built, which is evidently the assumption SE/vsbuild is making.  I include in my projects all of the documentation files, test data, pertinent emails, you name it.  Apparently I can only work this way if I use custom makefiles, which is disappointing, although not entirely surprising I suppose.  Now that I think about it, I guess every project I've worked with has been managed that way, and I've just been taking it for granted.

It would be nice though, if SE were enhanced with a seperate mechanism for specifying build dependencies that did not assume everything in the project was source.  Also, it does seem like a shortcoming that vsbuild doesn't understand it's own output files independently of the project properties.

Thanks for the enlightenment.

[Dennis]

The reason the exclusions did not work is probably because:
  1) spaces in the list of exclusions -- see my note about "no spaces"
  2) or, one of the files was locked, causing the build to fail -- try restarting the editor

Another option I should have mentioned yesterday, is for you to put the build directories in your exclusions:

Code: [Select]

*.vtg;*.vpj;*.vpw*;Debug\;Release\
FYI, I have filed bug reports about some of these problems:
  1) vsbuild should automatically ignore the .vpb file
  2) vsbuild should not include .o files in the build twice (even if they are in the project)
  3) better handling of exclude expressions (spaces, allow trailing semicolon)

[Steve Black]

Oh, the old, "Note, no spaces," clearly noted trick, eh?   

Yup, that did the trick.  On the bright side, forceing you to repeat yourself caused you to reveal the trick to excluding directories.  I had previously tried <dirname>\*, which did not work.  This is good.  I seem to be able put foreign files in my project tree and build the project as expected (at least for a simple project).

BTW, all of your bug reports look like good steps in good directions.

Thanks again,