workspace generation - nmakeoutput

Added by Kevin Thacker about 5 years ago

Having trouble with the jam workspace generation.

The exe has a path like this:

Y:/Code/Game/MyGame/build2010/pc-debug/MyGame/pc-debug/MyGame/MyGame.debug.exe

obj files are in subdirectories under this:

Y:/Code/Game/MyGame/build2010/pc-debug

The exe and main objs are in:

Y:/Code/Game/MyGame/build2010/pc-debug/MyGame

but there is another sub-directory in here:

Y:/Code/Game/MyGame/build2010/pc-debug/MyGame/pc-debug/MyGame

which is empty.

Any ideas?

It's probably my jam setup...


Replies (3)

RE: workspace generation - nmakeoutput - Added by Joshua Jensen about 5 years ago

Are there any samples within the JamPlus directory that illustrate this issue?

You are welcome to contact me offline, too.

I can't tell what is wrong without seeing a Jamfile, though.

Sorry.

-Josh

RE: workspace generation - nmakeoutput - Added by Kevin Thacker about 5 years ago

In C.ActiveTarget if I remove this line:

SubDir : $(C.ACTIVE_CONFIG_SPEC:J=-)/$(TARGET) ;

it then works for both command-line and workspace generation. both exes are in the same location.

We have a special rule:

rule SetTopDirectory {
PROJECT_DIR ?= $(SUBDIR) ;

ALL_LOCATE_TARGET ?= $(PROJECT_DIR)/.build/$(PLATFORM)/$(CONFIG) ;
}

this is at the top of each jam file, just under the initial SubDir .
This sets our build so that there is a .build directory, then platform then config.
It is how we like it, and all the files for a particular platform are grouped together.
Perhaps this is where it breaks down?

In addition our use of SubDir is probably not as recommended, we don't have a "TOP" for example.

We also calculate some relative directory paths based on a environment var.
e.g. "Include Core", "Include Render".
This uses an environment var that knows where the libraries are located, uses $(SUBDIR) to generate a relative path, and then uses SubIncludeRelative to pick it up.
This means we can have an exe that is not in the same build tree and the jam files are picked up and used.

RE: workspace generation - nmakeoutput - Added by Joshua Jensen about 5 years ago

Due to severe time constraints, I can only help with one part of your question right now.

Given the following file called helloworld.c:

#include <stdio.h>

int main() {
#if defined(HELLOWORLD_A)
    printf("Hello, worldA!\n");
#elif defined(HELLOWORLD_B)
    printf("Hello, worldB!\n");
#endif
    return 0;
}

which resides in the same directory as a Jamfile.jam:

SubDir TOP ;

C.Defines helloworldA : HELLOWORLD_A ;
C.Application helloworldA : helloworld.c ;

C.Defines helloworldB : HELLOWORLD_B ;
C.Application helloworldB : helloworld.c ;

The following things happen with the default provided Jambase and company and assuming a command-line build of PLATFORM=win32 and CONFIG=release with Visual C++:

  • Two compilations of helloworld.c occur (in parallel) with differing #defines.
  • The resultant helloworld.obj files end up in two separate directories: win32-release/helloworldA/helloworld.obj and win32-release/helloworldB/helloworld.obj
  • Two executables are created: win32-release/helloworldA/helloworldA.release.exe and win32-release/helloworldB/helloworldB.release.exe
  • No compilation errors occur due to parallel builds as every destination target is unique.

If you remove the SubDir : $(C.ACTIVE_CONFIG_SPEC:J=-)/$(TARGET) ; line as you describe above, the following happens:

  • Two compilations of helloworld.c occur (in parallel) with differing #defines.
  • The resultant helloworld.obj files are written to root directory of this Jam build.
  • Both may be successfully written, or the build may error out due to two files being written at the same time to a single location.
  • Assuming both are successfully written, two executables are written to the root directory of the Jam build: helloworldA.release.exe and helloworldB.release.exe
  • Both of the executables would have been linked against the same helloworld.obj, and your build is technically broken.

You refer again to the layout of the intermediate file directories with a comparison between an in-source directory run of Jam versus a workspace generated directory run of Jam. The workspace generator ends up adding the SubDir root name to the intermediate file path, but the in-source run of Jam does not. If I understand you right, this seems to be the cause of some concern for you.

Do you really care where all of the random compiler intermediate files specifically end up? The only outputs that should matter are the final built targets such as the executable, DLLs, or even static libraries, right? Those locations can be controlled through C.OutputPath and C.OutputName. Is there really a need for C.IntermediatePath?

It is hard to tell, but it sounds like you want both in-source builds and workspace generated 'out-of-source' builds to be one and the same. I really don't recommend this. You are giving up some useful functionality by doing so.

If I am misunderstanding anything, please clarify.

Thanks.

-Josh

(1-3/3)