0

I am using the DDK to build a project. Several of the build targets generate small internal libraries -- for simplicity, let's call them LibA.lib, LibB.lib, and LibC.lib. But the code for LibA references code from LibB and LibC. To use LibA in a project, you also need to include LibB.lib, and LibC.lib to resolve all of the dependencies. What I want to do is link LibB and LibC into LibA such that a user only needs to include LibA.lib. How can I accomplish this?

The SOURCES file for LibA looks something like this:

TARGETNAME=LibA
TARGETTYPE=LIBRARY

TARGETPATH=..\lib\$(DDKBUILDENV)

INCLUDES = .; \
           ..\LibB; \
           ..\LibC; \
           $(CRT_INC_PATH) \
           $(SDK_INC_PATH)

SOURCES = LibA_main.cpp \
          LibA_file2.cpp \
          LibA_file3.cpp

I understand that you can manually link libraries with link.exe; e.g.,

link.exe /lib LibA.lib LibB.lib LibC.lib

But if possible, I would like some way to achieve this same effect as a part of the build process for LibA, because some targets at a later point of the build process rely on LibA.

Thanks!

user1354557
  • 2,413
  • 19
  • 29

3 Answers3

1

I realize this is a late answer and it may not even be what you want in the end. However, ddkbuild.cmd has a pretty nifty mechanism to run actions before and after a build inside a particular directory.

We use this in one of our driver libraries which necessarily gets built as a number of static libraries and as a final step linked into one big static library much like you want. If you are able to use something like ddkbuild.cmd in your project, this would provide a solution and it's a solution that would work in automated builds, too.

NB: as far as I'm aware you cannot achieve what you want directly with build.exe. However, it's well possible that with some make (NMake) file acrobatics you could achieve a similar result. So the question is whether it's worth reinventing the wheel when there is one already.

0xC0000022L
  • 20,597
  • 9
  • 86
  • 152
  • I wanted to achieve this effect entirely through nmake because then I could just type `build` and make all the subprojects at once. I attempted to get post-build operations working with `NTTARGETFILE2`, but since build order mattered, my success was dependent on a race condition. What I ended up doing was writing a generic wrapper script that individually built each subproject in some given sequence -- this allowed me to use `NTTARGETFILE2` with linker commands and other post-build operations in `makefile.inc` without any problems. Anyway, +1 for `ddkbuild.cmd`; it's pretty useful. – user1354557 Feb 19 '13 at 16:30
0

The lib utility can combine libraries. Using your example, the command would be:

lib /out:CombinedLib.lib LibA.lib LibB.lib LibC.lib
Carey Gregory
  • 6,836
  • 2
  • 26
  • 47
  • Thanks for the response, but this solution is functionally equivalent to the one I mentioned with link.exe. What I'm looking for is something that integrates directly into the build process (e.g., perhaps a macro similar to TARGETLIBS). I still haven't found a way to do this, so it may not even be possible, but as of now, I need to run a batch script which builds LibA, then links LibA, then individually builds every other project that relies on the assumption that LibA contains LibB and LibC. It's pretty ugly. – user1354557 Sep 10 '12 at 22:11
0

I have encountered the same situation as you. Google a lot of and still have no solution. Fortunately, I found a way to resolve it finally. You can try it, add the below statement in your libA sources file.

LIBRARIAN_FLAGS = $(LIBRARIAN_FLAGS) libB.lib libC.lib
ЯegDwight
  • 24,821
  • 10
  • 45
  • 52
  • 1
    This is not an answer to the question. – bmargulies Sep 14 '12 at 20:57
  • Very late reply, but actually, @bmargulies, this is an answer to the question. +1. I was looking for a way within the build process to statically link other libraries to the target library (LibA). That is precisely what this does. However, if the libraries you want to link into LibA are also built as part of the build process, there is a race condition, because you cannot guarantee that they have been created yet without enforcing build order via a wrapper script of some sort. `build.exe` runs the builds in parallel. – user1354557 Feb 19 '13 at 16:31