workspace generation - dlls - bug.

Added by Kevin Thacker about 5 years ago

EDIT: It appears to be from a bug in my jamfiles.

I have this setup:


TextureDll.dll has a dependency on BaseDll.dll
MaterialDll.dll has a dependency on Basedll.dll
MaterialTool.exe has a dependency on TextureDll.dll and MaterialDll.dll

In MaterialTool.exe I use a subinclude to include the dll for texturedll and materialdll so it can link against their export libs.

SubInclude .. TextureDll ;
SubInclude .. MaterialDll ;

In the jam file for texturedll.dll I have a subinclude to basedll.dll to link against it's export lib.

SubInclude .. BaseDll ;

In the jam file for materialdll.dll I have a subinclude to basedll.dll to link against it's export lib.

SubInclude .. BaseDll ;

I can build materialtool and it builds all necessary dlls.
I can build materialdll and texturedll seperately and they build the basedll as needed. build works fine.

This was only way I could see to have dependant dlls built and linked against in this way.

The problem comes when I try and build a visual studio solution for materialtool.exe.

What I should see is a solution for materialtool, a project for materialtool, a project for texturedll.dll, a project for materialdll.dll and a project for basedll.dll.

It never gets this far, it sees basedll.dll jam file a second time and complains about a mismatched { } for some reason.

(materialtool is a c.application, materialdll is a c.library - but as a dll, same for the other two dlls).

Does this setup work for visual studio project generation or is this a bug?


targetinfo.!all!.!all!.lua has the dll listed twice:

Projects['basedll'].Name = 'basedll'

Projects['basedll'].Name = 'basedll'

when generating a workspace, if the same project is found, it should not add it again.

Replies (4)

RE: workspace generation - dlls - bug. - Added by Kevin Thacker about 5 years ago

There is and isn't a bug, it's down to the way I've used it.

This is exactly what is happening now I've worked it out:

in each of the dlls (as above) there is a relative include for a common-library they all use.
within the jam file I set a variable INCLUDED_LIBRARIES += Core ;
Then outside of that, I do this:

c.LinkLibraries $(TARGET) : $(INCLUDED_LIBRARIES) ;

I am doing this so I can have other libs and it automatically expands and links them.

What happens though, with the nested dlls, is that subinclude doesn't include it again, it's seen it once. The INCLUDED_LIBRARIES var doesn't get updated, and in one case the value is empty.

C.LinkLibraries sees an empty string. Jam handles it, but the workspace generator chokes. It generates bad code.

RE: workspace generation - dlls - bug. - Added by Kevin Thacker about 5 years ago

Attached is a similar setup, this one works for some reason.

I'll see if I can make one that doesn't.

note the REQLIB+= in Coredll, and the other dlls using it from this variable. declared locally in each so it doesn't pollute the others. (2.47 KB)

RE: workspace generation - dlls - bug. - Added by Joshua Jensen about 5 years ago

I think the response at discusses this point.

Let me know if the answer is not clear.


RE: workspace generation - dlls - bug. - Added by Kevin Thacker almost 5 years ago

When generating a workspace, and if you have some dlls re-using the same base lib, I noticed that the generated lua files seem to have the information repeated.

This didn't cause a problem for the generated workspace, but for one of our tools, it took half a minute to generate the workspace, where it was very quick for the other tools. I don't know if you could add it 1 time and it would be quicker to generate the workspace?

I found a few bugs today (nextgen):

1. In the following example, if I have this in my jamfile and I build with jam:

local FILES2 ;

local FILES = FileMain.cpp ;
Project MyApp : $(FILES) $(FILES2);
Echo "This is added " ;

In this example, jam doesn't give an error when building and also doesn't emit the Echo.

When generating a workspace however, there are 2 extra files "Echo" and "This is added".

Jam didn't tell me about the typo like it normally does.

2. I used this line (omitting the directory by mistake):
jam --workspace --gen=vs2010 jamfile.jam

I used it in the directory where my jamfile was.

The workspace generation wrote over my existing jamfile.jam with it's own.

3. I found a problem where the workspace generation failed with an error message from lua, if I had:

SubDir TOP Lib ;

local FILES = File1.cpp ;

Project Lib : $(FILES) ;

local LIBS = ; ######
C.LinkLibraries $(THIS_LIB) : $(LIBS) ; ######

C.Library Lib : $(FILES) : lib ;

  1. added to show the problem lines.
    The C.LinkLibraries is the problem when nothing is passed, if I remove that line, the generation works.

jam builds fine with the lines above, the workspace generation fails.

The jam script above is an example that reproduces the problem.

BTW, thank you for your other replies, it's definitely helping.