When I add an .asm file in sources I get a failure that it doesn't know how
to build it.
I don't really care about that, what I really want is the .obj from the .asm
(which I can build separately) to be included in the lib. With other lib
programs, they typically give + and +- options to add .obj to existing .lib
files. I didn't see such an option when running "lib" at the command prompt
in the build environment. Is there a way to add the .obj to a .lib
(DRIVER_LIBRARY) either in SOURCES file or via command line without
affecting the .lib built with the other .c files ?
TIA!!
"David F." <df2...@community.nospam> wrote in message
news:72FDD491-C1AA-4840...@microsoft.com...
MAJORCOMP= ntos
MINORCOMP= acme
# support running on SMP machines (DO NOT USE)
# NT_UP= 0
INCLUDES=x:\libs\inc
#
# determine DDK
#
C_DEFINES=/DWIN_DDK_BUILD
!if "$(_BUILDARCH)"=="AMD64"
C_DEFINES=$(C_DEFINES) /DDDK_AMD64
!elseif "$(DDK_TARGET_OS)"=="WinXP"
C_DEFINES=$(C_DEFINES) /DDDK_XP
!elseif "$(DDK_TARGET_OS)"=="WinNET"
C_DEFINES=$(C_DEFINES) /DDDK_2K3
!elseif "$(DDK_TARGET_OS)"=="Win2K"
C_DEFINES=$(C_DEFINES) /DDDK_W2K
!else
C_DEFINES=$(C_DEFINES) /DDDK_NT4
!endif
----- SOURCES ----
!INCLUDE x:\MYSOURCES.DEF
TARGETNAME=fsup
TARGETTYPE=DRIVER_LIBRARY
# set warning level for this target
MSC_WARNING_LEVEL=/W3 /WX /FR /FAcs
# build conditional defines
C_DEFINES=$(C_DEFINES) /DASM_SUB
# include paths
INCLUDES=..\..;$(INCLUDES)
# put it in a directory
TARGETPATH=..\..\ddk\$(DDK_TARGET_OS)
# source files for build
SOURCES=\
f1.c \
f2.c \
f3.c \
f4.c \
a1.asm
"David Craig" <dri...@noemail.noemail> wrote in message
news:%23zhPZtX...@TK2MSFTNGP04.phx.gbl...
lib libfile.lib objfile.obj
"David F." <df2...@community.nospam> wrote in message
news:72FDD491-C1AA-4840...@microsoft.com...
<snip>
> what I really want is the .obj from the .asm (which I can build
> separately) to be included in the lib. With other lib programs, they
> typically give + and +- options to add .obj to existing .lib files. I
> didn't see such an option when running "lib" at the command prompt in the
> build environment.
<snip>
"David F." <df2...@community.nospam> wrote in message
news:D6D2D2A1-3216-4F1C...@microsoft.com...
It is bad practice to include absolute paths in your build procedures,
especially one with a drive letter. Use relative paths instead. Also, the
".DEF" extension is traditionally used for DLL import files. ".INC" is
traditionally used for makefile includes.
>TARGETNAME=fsup
>TARGETTYPE=DRIVER_LIBRARY
>
># set warning level for this target
>MSC_WARNING_LEVEL=/W3 /WX /FR /FAcs
Only /W3 and /WX are warning levels. /FR and /FAcs should be moved to
C_DEFINES.
># build conditional defines
>C_DEFINES=$(C_DEFINES) /DASM_SUB
>
># include paths
>INCLUDES=..\..;$(INCLUDES)
>
># put it in a directory
>TARGETPATH=..\..\ddk\$(DDK_TARGET_OS)
>
># source files for build
>SOURCES=\
>f1.c \
>f2.c \
>f3.c \
>f4.c \
>a1.asm
Assembler files must be placed in a subdirectory corresponding to the
architecture. Assuming your a1.asm file is an x86 file, move it to a
directory called i386, and change sources to:
SOURCES = \
f1.c \
f2.c \
f3.c \
f4.c
I386_SOURCES = \
i386\a1.asm
When you write the x64 version, you can add it as well:
AMD64_SOURCES = \
amd64\a1.asm
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
"Tim Roberts" <ti...@probo.com> wrote in message
news:vifcg51vbgevpco6m...@4ax.com...
> Assembler files must be placed in a subdirectory corresponding to the
> architecture.
Is that documented? The page about SOURCES
http://msdn.microsoft.com/en-us/library/ms792148.aspx
doesn't say anything like that; on the contrary, it says:
"All files specified by this macro must be located in the
directory that contains the Sources file or in the parent
directory of the Sources file."
which would even seem to disallow an i386 subdirectory.
"Build Utility Limitations and Rules"
http://msdn.microsoft.com/en-us/library/ms792413.aspx
does mention SOURCES can list files in "the platform
subdirectory", but I didn't find anything that says
platform-specific files have to be placed in such a directory.
> I don't know. The final answer to all such questions is the source code,
> which we have, in bin\i386.mk and bin\amd64.mk. For the x86, it looks in
> i386 and ..\i386 for asm files. It doesn't look in ".".
Thanks. Could you also say which WDK version you checked?
I have 3790, 3790.1830, 6000, 6001.18001 and 7600 installed on this
machine, and it's the same on all of them. I know it has been this way
since the original NT 3.1 DDK, which happened to use a lot more assembler
code.