AW: AW: AW: [CMake] CMake 2.4.7: Generator "Visual Studio 7 .NET 2003" seems to ignore certain LINK_FLAGS properties (worked in 2.4.6)

[Gerhard Grimm]

Hi Bill,

I'm using the term "resource container" for a Win32 DLL containing no
executable code but only resources (in our case icons or messages texts
for the Windows event log). To build it, one needs to pass the /NOENTRY
flag to the linker.

Since my last message, I have managed to solve the problem of Visual
Studio wanting an import library for it as result of another target's
dependency on the resource DLL. Adding an empty .def file to the DLL's
sources made the linker create a dummy import library that did the trick.

It might be a clumsy solution, but it works for us and I see no point in
bothering you any longer. At last, we can start using CMake 2.4.7
tomorrow :-)

Thanks again for your help and patience!

Best regards,

Gerhard

-----Ursprüngliche Nachricht-----
Von: Bill Hoffman [mailto:bill.hoffman at kitware.com]
Gesendet: Dienstag, 31. Juli 2007 18:17
An: Gerhard Grimm
Cc: Bill Hoffman; cmake at cmake.org
Betreff: Re: AW: AW: [CMake] CMake 2.4.7: Generator "Visual Studio 7
.NET 2003" seems to ignore certain LINK_FLAGS properties (worked in
2.4.6)


Gerhard Grimm wrote:
> Hi Bill,
>
> thanks for your hints. The /DEF problem is fixed now.
>
> However, changing the resource container's target type from executable
> to library (to avoid passing the /DLL flag explicitly) raised another
> problem:
> The resource container (which BTW is not the target from my previous
> example, it only contains resources and has no exports) is added as
> dependency to another library target using
>
> add_dependencies(OtherLibrary ResourceContainer)
>
> [The reason for this is the creation of a header file by a custom command
> when building the resource container. This header file contains resource
> IDs and is needed when building the OtherLibrary.]
>
> Since the ResourceContainer is now considered a library by Visual Studio,
> it attempts to link the OtherLibrary with it by adding a non-existing
> import library to the OtherLibrary's linker command line, although this
> is mentioned nowhere in the generated project file.
>
> I'll try to build a dummy import library for the ResourceContainer...
>   
OK, you lost me, I have no idea what a ResourceContainer is...
If you could give a complete example that shows your problem I might be 
able to help.
We have lots of Qt based projects that generate .h files with custom 
commands.
As long as the .h files are in your source list things should work.  

-Bill