Hi,
I am in search for a better method to create a LIB file (to link elsewhere into drivers) than via the ordinary BUILD method. The problem is, that BUILD doesn't like directory hierarchies, so what we do now is to create a number of LIBs and have the linker link them together in a final step.
Is there a better method?
Thanks in advance,
DDKWizard and DDKBUILD: http:
Trunk (potentially unstable) version: http:</http:></http:>
“Oliver Schneider” wrote in message
news:xxxxx@ntdev…
> Hi,
>
> I am in search for a better method to create a LIB file (to link elsewhere
> into drivers) than via the ordinary BUILD method. The problem is, that
> BUILD doesn’t like directory hierarchies, so what we do now is to create a
> number of LIBs and have the linker link them together in a final step.
>
> Is there a better method?
Hi Oliver,
Build can handle directory trees and dependencies of subprojects using the
DIRS file.
This works for quite a while for many developer teams.
What’s the problem?
Regards,
–PA
Hi Pavel,
thanks for your response.
Build can handle directory trees and dependencies of subprojects using the
DIRS file.
This works for quite a while for many developer teams.
What's the problem?
I am aware of DIRS files, but they merely "connect" several *projects*. After all every SOURCES file creates some kind of build result, right? However, there doesn't seem to be a straightforward way to create single LIB from source files which are spread throughout a directory hierarchy without actually having a final (separate) linker step.
/lib (DIRS)
/part1 (DIRS)
/part11 (SOURCES)
/part12 (SOURCES)
/part13 (SOURCES)
/part2 (DIRS)
/part21 (SOURCES)
/part22 (SOURCES)
/part23 (SOURCES)
/part3 (DIRS)
/part31 (SOURCES)
/part32 (SOURCES)
/part33 (SOURCES)
/console
Let's say I want to build a single LIB file from ./part11 through ./part33, how would I do that? I cannot reach into subfolders or parent folders from a SOURCES file easily.
Thanks,
DDKWizard and DDKBUILD: http:
Trunk (potentially unstable) version: http:</http:></http:>
> I cannot reach into subfolders or parent folders
This has been discussed before.
The [awful] solution I use - but cannot recommend - is using fake source
files.
For each inaccessible source file …\part12\inaccessible_source_file.cpp you
create
inaccessible_source_file.cpp in your part11 folder containing just 2 lines:
// part11/inaccessible_source_file.cpp
#include "…\part12\inaccessible_source_file.cpp // bring it in
[What??? To #include a source file???]
Ugly.
I use it b/c other solutions are no better IMHO.
Btw, windbg somehow gets through just fine and finds source lines
where they are, in a real file.
----- Original Message -----
From: “Oliver Schneider”
To: “Windows System Software Devs Interest List”
Sent: Friday, October 24, 2008 12:01 PM
Subject: Re: Re:[ntdev] Better method to build a driver LIB (DRIVER_LIBRARY)
file?
> Hi Pavel,
>
> thanks for your response.
>
>> Build can handle directory trees and dependencies of subprojects using
>> the
>> DIRS file.
>> This works for quite a while for many developer teams.
>> What’s the problem?
> I am aware of DIRS files, but they merely “connect” several projects.
> After all every SOURCES file creates some kind of build result, right?
> However, there doesn’t seem to be a straightforward way to create single
> LIB from source files which are spread throughout a directory hierarchy
> without actually having a final (separate) linker step.
>
> /lib (DIRS)
> /part1 (DIRS)
> /part11 (SOURCES)
> /part12 (SOURCES)
> /part13 (SOURCES)
> /part2 (DIRS)
> /part21 (SOURCES)
> /part22 (SOURCES)
> /part23 (SOURCES)
> /part3 (DIRS)
> /part31 (SOURCES)
> /part32 (SOURCES)
> /part33 (SOURCES)
> /console
>
> Let’s say I want to build a single LIB file from ./part11 through
> ./part33, how would I do that? I cannot reach into subfolders or parent
> folders from a SOURCES file easily.
>
>
> Thanks,
>
> // Oliver
> –
> ---------------------------------------------------
> DDKWizard and DDKBUILD: http:
>
> Trunk (potentially unstable) version:
> http:
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer</http:></http:>
Oliver Schneider wrote:
Hi,
I am in search for a better method to create a LIB file (to link elsewhere into drivers) than via the ordinary BUILD method. The problem is, that BUILD doesn’t like directory hierarchies, so what we do now is to create a number of LIBs and have the linker link them together in a final step.
Is there a better method?
Probably, but not if you want to use “build”. I would point out that
the one-library-per-directory scheme is exactly how Windows and Windows
CE are themselves built.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
There are two issues at play with how BUILD and MAKEFILE.NEW conspire to
make the easy very difficult in this regard:
David R. Cattley wrote:
Someday we can have a BUILD.EXE & NMAKE & MAKEFILE.NEW which don’t force us
into this nonsense. Or maybe not.
It has been just shy of 20 years since this mechanism was introduced. I
find it highly unlikely that this will ever change. Perhaps when
Singularity goes mainstream…
This mechanism does enforce a healthy level of isolationism. It makes
it somewhat difficult to embed complicated, cross-directory dependencies.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
Oliver Schneider
Sent: Friday, October 24, 2008 3:16 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Better method to build a driver LIB
(DRIVER_LIBRARY) file?I am in search for a better method to create a LIB file (to
link elsewhere into drivers) than via the ordinary BUILD
method. The problem is, that BUILD doesn’t like directory
hierarchies, so what we do now is to create a number of LIBs
and have the linker link them together in a final step.
What is wrong with this method? Or better, what gain are you expecting
to achieve? I understand it is a bit tedious to create such a structure
(one I did it for rather big existing sources base) but once it is done
it works and results are equivalent.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
> -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, October 24, 2008 8:20 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Better method to build a driver LIB
(DRIVER_LIBRARY) file?This mechanism does enforce a healthy level of isolationism. It makes
it somewhat difficult to embed complicated, cross-directory
dependencies.
Yes. I’m working with two build engines in parallel; our one allows to
use files anywhere in the tree and MS build doesn’t. I can’t say what
approach is better. Our one has freedom but on the other hand needs
discipline and careful planning from programmers. It is easy to make a
mess this way. The other one is strict and doesn’t allow to wreak havoc
easily.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
Tim,
In case it was not obvious, my money is on ‘not’ 
I tend now to setup projects, even ones that do not involve NTBUILD, within
the narrow confines of how NTBUILD works. It only sucks when you have to
take some gigantic ‘over engineered’ effort for some other build environment
and just make it work in NTBUILD. At that point, I tend to pull out all of
the stops, put the clothespin on my nose, and do what it takes.
20 years? Given that much time, we can be sure it will at this point never
change.
Cheers,
-dave
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, October 24, 2008 2:20 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Better method to build a driver LIB (DRIVER_LIBRARY)
file?
David R. Cattley wrote:
Someday we can have a BUILD.EXE & NMAKE & MAKEFILE.NEW which don’t force
us
into this nonsense. Or maybe not.
It has been just shy of 20 years since this mechanism was introduced. I
find it highly unlikely that this will ever change. Perhaps when
Singularity goes mainstream…
This mechanism does enforce a healthy level of isolationism. It makes
it somewhat difficult to embed complicated, cross-directory dependencies.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
> Let’s say I want to build a single LIB file from ./part11 through
./part33, how would I do that?
Create a .C file of a single line:
#include “…/part33/t.c”
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
“David R. Cattley” wrote in message news:xxxxx@ntdev…
…
> Someday we can have a BUILD.EXE & NMAKE & MAKEFILE.NEW which don’t force
> us
> into this nonsense. Or maybe not.
The root cause of tree structure limitation seems to be nmake.
For example, GNU make has “vpath” statement and pattern rules (%) - that
allows it
to place sources and targets more flexibly.
And nmake is very, very old…
However, the build docum says that other make programs besides nmake
are not supported 
Regards,
–PA
“Alex Shvedov” wrote in message news:xxxxx@ntdev…
>> I cannot reach into subfolders or parent folders
> This has been discussed before.
> The [awful] solution I use - but cannot recommend - is using fake source
> files.
Hmm, then… those who want to play these linuxy games,
can create symlinks (or hard links) to the .c files in same folder with
SOURCES.
Windows does support links.
( IMHO, strange structure of source directories is often self-inflictied
damage,
or maybe a team management issue, when several ambitious “agile” folks
must be prevented from fighting over common files , rather than
cooperating )
–PA
Pavel,
I am no expert here, just a user. I agree that path style inference rules
in NMAKE would have been nice but that is easily overcome with just more
inference rules. The real issue as I know it in the BUILD/NMAKE ‘system’ of
tools is BUILD. It processes the SOURCES macro to generate the objects.inc
file as well as maintain a persistent dependency graph (build.dat). It is
BUILD.EXE that imposes the restriction on paths. Since BUILD will not be
able to locate the source dependencies, it will always assume that the
target is out of date and force it to be rebuilt as BUILD ‘drives’ NMAKE in
this respect with command line options which cause the target to be compiled
in Phase 1 - or at least that is what my limited investigations into the
operation seem to reveal (done over many years and thus might not be quite
right for the current tools). That is why IMO these kinds of workarounds
all ‘work’ but suffer the side-effect of always recompiling.
A pure NMAKE based build solution over a complex tree would suffer a huge
performance penalty as each NMAKE process rebuilt and re-created the
dependency graph anew. I think the creator of BUILD had the goal of
calculating the dependency graph *infrequently* and persisting it so that it
need only be *evaluated* for each target. Across a large enough system
(like NT) this surely is a huge reduction in build times.
And of course I will not be surprised to learn that GNU make has a similar
capability/optimization built in. Alas, if so, I am not able to leverage
it in my work.
Cheers,
-dave
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Saturday, October 25, 2008 1:32 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Re:Better method to build a driver LIB (DRIVER_LIBRARY)
file?
“David R. Cattley” wrote in message news:xxxxx@ntdev…
…
> Someday we can have a BUILD.EXE & NMAKE & MAKEFILE.NEW which don’t force
> us
> into this nonsense. Or maybe not.
The root cause of tree structure limitation seems to be nmake.
For example, GNU make has “vpath” statement and pattern rules (%) - that
allows it
to place sources and targets more flexibly.
And nmake is very, very old…
However, the build docum says that other make programs besides nmake
are not supported
Regards,
–PA
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
David,
Of course I’m very far from being expert in the build system, but
some facts support my guesses:
build.exe is not required to make a simple project (one SOURCE /
makefile):
After the environment is set up, you can just run nmake instead of build,
and
nmake alone does the job.
All the .c files are listed in SOURCES; build can see them all
to check dependencies or whatever it does, no matter how their paths look.
Regards,
– pavel
“David R. Cattley” wrote in message news:xxxxx@ntdev…
> Pavel,
>
> I am no expert here, just a user. I agree that path style inference rules
> in NMAKE would have been nice but that is easily overcome with just more
> inference rules. The real issue as I know it in the BUILD/NMAKE ‘system’
> of
> tools is BUILD. It processes the SOURCES macro to generate the
> objects.inc
> file as well as maintain a persistent dependency graph (build.dat). It is
> BUILD.EXE that imposes the restriction on paths. Since BUILD will not be
> able to locate the source dependencies, it will always assume that the
> target is out of date and force it to be rebuilt as BUILD ‘drives’ NMAKE
> in
> this respect with command line options which cause the target to be
> compiled
> in Phase 1 - or at least that is what my limited investigations into the
> operation seem to reveal (done over many years and thus might not be quite
> right for the current tools). That is why IMO these kinds of workarounds
> all ‘work’ but suffer the side-effect of always recompiling.
>
> A pure NMAKE based build solution over a complex tree would suffer a huge
> performance penalty as each NMAKE process rebuilt and re-created the
> dependency graph anew. I think the creator of BUILD had the goal of
> calculating the dependency graph infrequently and persisting it so that
> it
> need only be evaluated for each target. Across a large enough system
> (like NT) this surely is a huge reduction in build times.
>
> And of course I will not be surprised to learn that GNU make has a similar
> capability/optimization built in. Alas, if so, I am not able to leverage
> it in my work.
>
> Cheers,
> -dave
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
> Sent: Saturday, October 25, 2008 1:32 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Re:Better method to build a driver LIB
> (DRIVER_LIBRARY)
> file?
>
> “David R. Cattley” wrote in message
> news:xxxxx@ntdev…
> …
>> Someday we can have a BUILD.EXE & NMAKE & MAKEFILE.NEW which don’t force
>> us
>> into this nonsense. Or maybe not.
>
> The root cause of tree structure limitation seems to be nmake.
> For example, GNU make has “vpath” statement and pattern rules (%) - that
> allows it
> to place sources and targets more flexibly.
> And nmake is very, very old…
> However, the build docum says that other make programs besides nmake
> are not supported
>
> Regards,
> --PA
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
Hi Oliver,
Do you want to merge several LIBs built with the usual WDK procedure,
into one LIB?
Sorry, don’t know how to do this with the build utilities
(never tried or needed); maybe you can simply run lib (= link /lib)
to merge the libs, instead?
C files can be located in the parent dir of SOURCES
(referred as …\ ) If this doesn’t work for you, can you please give
more details?
Another idea could be to place the files in folders virtually, while
they really are in same filesystem folder at the build time:
For example, in VC++ GUI you can create several “folders” (or they call
it “filters”?).
Some source control systems allow to assign a different location to get
or check out files - so you can get them all into one flat directory.
As the last resort, create NTFS links to the .c files in one flat dir…
Regards,
–PA
Oliver Schneider wrote:
Hi Pavel,
thanks for your response.
> Build can handle directory trees and dependencies of subprojects using the
> DIRS file.
> This works for quite a while for many developer teams.
> What’s the problem?
I am aware of DIRS files, but they merely “connect” several *projects*. After all every SOURCES file creates some kind of build result, right? However, there doesn’t seem to be a straightforward way to create single LIB from source files which are spread throughout a directory hierarchy without actually having a final (separate) linker step./lib (DIRS)
/part1 (DIRS)
/part11 (SOURCES)
/part12 (SOURCES)
/part13 (SOURCES)
/part2 (DIRS)
/part21 (SOURCES)
/part22 (SOURCES)
/part23 (SOURCES)
/part3 (DIRS)
/part31 (SOURCES)
/part32 (SOURCES)
/part33 (SOURCES)
/consoleLet’s say I want to build a single LIB file from ./part11 through ./part33, how would I do that? I cannot reach into subfolders or parent folders from a SOURCES file easily.
Thanks,
// Oliver
Hi everyone,
and thanks for all the replies. I'll answer to them in the order they arrived in my mailbox in this one long mail (so I do not pollute the list unnecessarily).
For each inaccessible source file ..\part12\inaccessible_source_file.cpp
you create inaccessible_source_file.cpp in your part11 folder containing just 2
lines:// part11/inaccessible_source_file.cpp
#include "..\part12\inaccessible_source_file.cpp // bring it in[What??? To #include a source file???]
Ugly.
I use it b/c other solutions are no better IMHO.
Alex, indeed I was thinking of this method, but it contradicts the goal of automating the build as much as possible. New files appear and old ones disappear in the folder structure over time. So we would be maintaining even more files than before.
Probably, but not if you want to use "build". I would point out that
the one-library-per-directory scheme is exactly how Windows and Windows
CE are themselves built.
Tim, I know. But this doesn't necessarily mean that there is no other way (I hoped)
MAKEFILE.INC is your potential friend here. In it you may create your own
inference rules to wherever you source files exist.
David, thanks. That's a good pointer. Can you give me a hint which of the rules could be best used to reach the goal? I have had a look into MAKEFILE.NEW in order to find out what should be done in MAKEFILE.INC, but I don't get it.
And for what it is worth, the technique of using 'surrogate' target files
that include the actual target file does not confuse BUILD nor
MAKEFILE.NEW nor the debugger (as you have pointed out) since the PDB gets the full
path to the source files *and* #include files. Things get a little tricky
with precompiled header usage (the #include must be in the surrogate) but even
that is not all that onerous.
David: Only, the "surrogate" source files will be those which contain the #include clause.
What is wrong with this method? Or better, what gain are you expecting
to achieve? I understand it is a bit tedious to create such a structure
(one I did it for rather big existing sources base) but once it is done
it works and results are equivalent.
Michal, surely I would have done that already, if it was an option. It isn't. The simple problem is, that the team that is working on the source tree I am talking about is pretty conservative and that we (my team) are now challenged with creating a single driver LIB that can be used by third parties. Changing the structure is not up for debate.
I tend now to setup projects, even ones that do not involve NTBUILD,
within the narrow confines of how NTBUILD works. It only sucks when you have to
take some gigantic 'over engineered' effort for some other build
environment and just make it work in NTBUILD. At that point, I tend to pull out all
of the stops, put the clothespin on my nose, and do what it takes.
David, bingo - exactly the case here. Also, the interesting part is that the source tree in question is otherwise built with numerous compilers on numerous processor platforms/operating systems/build environments. So yes, the structure is liberal, but apart from BUILD.EXE no other tool has trouble with it.
Hmm, then... those who want to play these linuxy games,
can create symlinks (or hard links) to the .c files in same folder with
SOURCES.
Windows does support links.
Pavel, hardlinks are too volatile and symlinks only exist in Vista and later for files. Why are hardlinks volatile? Well, most applications are totally unaware of them. Try editing a .doc file in MS Word - it'll break the hardlink every single time, because of the way it opens/copies/renames the files.
( IMHO, strange structure of source directories is often self-inflictied
damage, or maybe a team management issue, when several ambitious "agile" folks
must be prevented from fighting over common files , rather than cooperating )
Pavel: Well, sometimes it's rather a legacy. And if I could disclose more about the structure you would perhaps not find it too strange after all. It's just that BUILD.EXE imposes more restrictions than other build tools.
Do you want to merge several LIBs built with the usual WDK procedure,
into one LIB?
Pavel: Yes, this is what I want to achieve.
Sorry, don't know how to do this with the build utilities
(never tried or needed); maybe you can simply run lib (= link /lib)
to merge the libs, instead?
Pavel: That's what we do at the moment due to the lack of a more elegant way. My problem with this is, that it relies on a feature of DDKBUILD.CMD (ddkpostbld.cmd) and therefore wouldn't work with the OSR .bat or Mark Roddy's version. A method based solely on the WDK build environment would be perfect. But as I saw from the discussion the only trick (by David) that may do it will cause lots of unnecessary compiles.
C files can be located in the parent dir of SOURCES
(referred as ..\ ) If this doesn't work for you, can you please give
more details?
Pavel: It doesn't work because the tree is branched further than just one level.
Another idea could be to place the files in folders virtually, while
they really are in same filesystem folder at the build time:
Pavel: Sadly the directory structure will not be changed. It's not a matter of "can" or "should", but rather that it isn't even up for debate.
Thanks for all your help.
I'll further look into what MAKEFILE.INC can do for me in the respective subfolders, but if it doesn't work, I'll stick with what we have at the moment. Just thought that someone here found a really elegant way around how BUILD.EXE works.
DDKWizard and DDKBUILD: http:
Trunk (potentially unstable) version: http:</http:></http:>
Oliver,
> MAKEFILE.INC is your potential friend here. In it you may create your own
> inference rules to wherever you source files exist.
David, thanks. That’s a good pointer. Can you give me a hint which of the
rules could be best used to reach the goal? I have had a look into
MAKEFILE.NEW in order to find out what should be done in MAKEFILE.INC, but I
don’t get it.
Look in MAKEFILE.NEW for the inference rules defined to compile a .C file to
a .OBJ file. There will be quite a few of them differing only in the source
path and destination path portions of the rule. Using them as a guide (aka,
copy them and update the source path), add some rules to MAKEFILE.INC.
NMAKE will then be able to infer that the .C file *may* come from the path
specified in the inference rule.
Keep in mind this does not make BUILD understand how to find your source
file and scan it for dependencies.
> And for what it is worth, the technique of using ‘surrogate’ target files
> that include the actual target file does not confuse BUILD nor
> MAKEFILE.NEW nor the debugger (as you have pointed out) since the PDB gets
the full
> path to the source files and #include files. Things get a little
tricky
> with precompiled header usage (the #include must be in the surrogate) but
even
> that is not all that onerous.
David: Only, the “surrogate” source files will be those which contain the
#include clause.
Just to be sure my comment is understood:
If your original .C file has looks like this:
#include “precomp.h”
…
And you create a surrogate that looks like this:
#include “…......\foolib\src\wingding\myfile.c”
And try to compile that with the precompiled header option, the compiler
balks because it does not see an #include “precomp.h” as the first
interesting thing in the compiland.
The surrogate actually needs to look like this:
#include “precomp.h”
#include “…......\foolib\src\wingding\myfile.c”
Make sure you protect precomp.h from multiple includes. The point is to
recognize that the surrogate is the compiland now, not the original source
file.
Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development
David,
Look in MAKEFILE.NEW for the inference rules defined to compile a .C file
to a .OBJ file. There will be quite a few of them differing only in the
source path and destination path portions of the rule. Using them as a guide
(aka, copy them and update the source path), add some rules to MAKEFILE.INC.NMAKE will then be able to infer that the .C file *may* come from the path
specified in the inference rule.
Okay, that sounds good. I'll ask back, should I "hit the wall"
Keep in mind this does not make BUILD understand how to find your source
file and scan it for dependencies.
Thus the recompile, right?
Just to be sure my comment is understood:
If your original .C file has looks like this:
#include "precomp.h"
....And you create a surrogate that looks like this:
#include "........\foolib\src\wingding\myfile.c"
And try to compile that with the precompiled header option, the compiler
balks because it does not see an #include "precomp.h" as the first
interesting thing in the compiland.The surrogate actually needs to look like this:
#include "precomp.h"
#include "........\foolib\src\wingding\myfile.c"Make sure you protect precomp.h from multiple includes. The point is to
recognize that the surrogate is the compiland now, not the original source
file.
Okay, got that.
Thanks a bunch for your help, it's very much appreciated!
DDKWizard and DDKBUILD: http:
Trunk (potentially unstable) version: http:</http:></http:>
> As the last resort, create NTFS links to the .c files in one flat dir…
Unless your scc is too stupid to handle this correctly. Last I checked, StarTeam, for example, stores all links pointing to the
same file as unique files.
There are a lot of things about BUILD that I do not like, but this issue (nested library builds) is not one that I would personally
try to work around, as it works well enough, for me at least.
mm
Pavel A. wrote:
Hi Oliver,
Do you want to merge several LIBs built with the usual WDK procedure,
into one LIB?
Sorry, don’t know how to do this with the build utilities
(never tried or needed); maybe you can simply run lib (= link /lib)
to merge the libs, instead?C files can be located in the parent dir of SOURCES
(referred as …\ ) If this doesn’t work for you, can you please give
more details?Another idea could be to place the files in folders virtually, while
they really are in same filesystem folder at the build time:For example, in VC++ GUI you can create several “folders” (or they call
it “filters”?).
Some source control systems allow to assign a different location to get
or check out files - so you can get them all into one flat directory.As the last resort, create NTFS links to the .c files in one flat dir…
Regards,
–PAOliver Schneider wrote:
> Hi Pavel,
>
> thanks for your response.
>
>> Build can handle directory trees and dependencies of subprojects
>> using the
>> DIRS file.
>> This works for quite a while for many developer teams.
>> What’s the problem?
> I am aware of DIRS files, but they merely “connect” several
> *projects*. After all every SOURCES file creates some kind of build
> result, right? However, there doesn’t seem to be a straightforward way
> to create single LIB from source files which are spread throughout a
> directory hierarchy without actually having a final (separate) linker
> step.
>
> /lib (DIRS)
> /part1 (DIRS)
> /part11 (SOURCES)
> /part12 (SOURCES)
> /part13 (SOURCES)
> /part2 (DIRS)
> /part21 (SOURCES)
> /part22 (SOURCES)
> /part23 (SOURCES)
> /part3 (DIRS)
> /part31 (SOURCES)
> /part32 (SOURCES)
> /part33 (SOURCES)
> /console
>
> Let’s say I want to build a single LIB file from ./part11 through
> ./part33, how would I do that? I cannot reach into subfolders or
> parent folders from a SOURCES file easily.
>
>
> Thanks,
>
> // Oliver
