How could one make a wildcard dependency like boot/*.inc work in NMAKE?
This works for me, with VS 2017:
>type makefile
mytarget : boot\*.inc
!#echo $?
>dir/b boot
one.inc
two.inc
>nmake
boot\one.inc
boot\two.inc
The on-line documentation for NMAKE provided by Microsoft is simply awful.
In contrast, the older 59-page PDF document entitled Chapter 16: Managing Projects with NMAKE is vastly superior. It appears to agree with the current online version (an errata would be nice!). But it is surprisingly hard to find via Google; three possible links are:
http://www.engr.iupui.edu/~dskim/downloadable/reference_Nmake.pdf
https://www.scribd.com/document/19344397/Managing-Projects-With-NMAKE
https://cld.pt/dl/download/4275816b-59bc-4fe9-96a3-f2c7a24e9246/GnuCOBOL/MISC/Manuals%20%26%20Guides/Visual%20Studio%20%26%20SDKs/Managing%20Projects%20with%20NMAKE.pdf?download=true
A good way to find them via certain search engines: "Mike Eddy" nmake MSGRIDA1.DOT filetype:pdf
Related
I have a Windows 10 laptop where no TeX distribution was ever installed before (double-checked for config directories, files, and environment variables).
Wanting to install TeX Live 2021, I followed the full installation guide and also read the Windows-specific warnings. I've now tried several times, following different installation procedures - cleaning up everything (deleting base & user directories, environment variables, etc) before each time - but still don't manage to get a working installation. Before I report a bug at tex-live#tug, I wanted to ask for advice here, in case I'm doing something wrong. Here is what I did, step by step, and the problems I encountered in the process.
1. First I tried running the recommended online installer install-tl-windows.exe. It never got past the screen that tries to contact or load from a repository, even after a 30-min wait. Tried a dozen times, choosing different mirrors nearby and far away. No luck.
2. Then I downloaded and unpacked the install-tl.zip and run install-tl-windows.bat therein. This time the main installation window appeared. I left all default paths and environment variables (note that I do have write access to C:); in the selection scheme I unselected all languages except US & UK English, unselected XeTeX, LuaTeX, ConTeXt; also unselected TeXworks (I use Emacs), and clicked Install. After one to three hours (depending on the mirror I chose), the installation was complete.
I tried compiling a minimal latex document (see below), and got an error similar to the one in this old question:
I can't find the format file `pdflatex.fmt'
Following the advice in the answers to that question and similar questions elsewhere online such as this, I tried running texhash and fmtutil-sys --all. The latter gave the error
no appropriate script or programme found fmtutil.
for which there are also many posts online.
2a. Not understanding what the problem could be, I re-tried with all possible combinations of the following three options: (a) choosing different mirrors; (b) leaving the full selection of packages (ie without unselecting some languages, LuaTeX etc); (c) redoing the procedure by choosing "Run as Administrator". No luck.
3. At this point I tried downloading the ISO file with the full installation. Mounted the image and run install-tl-windows.bat (as normal user, as recommended; I repeat that I do have write access to C:). Everything proceeded as in step 2. above. At the end of the installation I tried running pdflatex on the minimal latex document. New error this time:
This is pdfTeX, Version 3.141592653-2.6-1.40.22 (TeX Live 2021/W32TeX) (preloaded format=pdflatex)
restricted \write18 enabled.
entering extended mode
(./minimal-template.tex
LaTeX2e <2020-10-01> patch level 4
L3 programming layer <2021-02-18>
! LaTeX Error: File `article.cls' not found.
Very strange. A file search revealed that article.cls is in the TeXLive file system; but kpathsea did not see it indeed.
4. At this point I opened the TeX Live Shell from the Start Menu; selected a CTAN mirror; updated the TL Manager which was not up to date; updated all packages; run Regenerate filename database; and run Regenerate formats. With the latter I got this error:
tex live shell:
mtutil [INFO]: total formats: 59
fmtutil [INFO]: exiting with status 53
C:\texlive\2021\bin\win32\runscript.tlu:915: command failed with exit code 53:
perl.exe c:\texlive\2021\texmf-dist\scripts\texlive\fmtutil.pl --sys --all
Here is a snip from the full set of errors appearing in the "Other" tab (I'm replacing my user directory with asterisks for privacy; note that I do have write access to these directories):
start load https://www.nic.funet.fi/pub/TeX/CTAN/systems/texlive/tlnet
finish load https://www.nic.funet.fi/pub/TeX/CTAN/systems/texlive/tlnet
start load http://contrib.texlive.info/current
finish load http://contrib.texlive.info/current
running mktexlsr ...
done running mktexlsr.
running mtxrun --generate ...
done running mtxrun --generate.
running updmap-sys ...
done running updmap-sys.
regenerating fmtutil.cnf in C:/texlive/2021/texmf-dist
running fmtutil-sys --byengine luatex --no-error-if-no-format --no-error-if-no-engine=luajithbtex,luajittex,mfluajit --status-file=C:\Users\***\AppData\Local\Temp\rPSb0Dpak2\WW_dJvUHgX ...
tlmgr.pl: fmtutil-sys --byengine luatex --no-error-if-no-format --no-error-if-no-engine=luajithbtex,luajittex,mfluajit --status-file=C:\Users\***\AppData\Local\Temp\rPSb0Dpak2\WW_dJvUHgX failed (status 255), output:
Unknown option: status-file
Try "fmtutil --help" for more information.
C:\texlive\2021\bin\win32\runscript.tlu:915: command failed with exit code 255:
perl.exe c:\texlive\2021\texmf-dist\scripts\texlive\fmtutil.pl --sys --byengine luatex --no-error-if-no-format --no-error-if-no-engine=luajithbtex,luajittex,mfluajit --status-file=C:\Users\***\AppData\Local\Temp\rPSb0Dpak2\WW_dJvUHgX
running fmtutil-sys --byengine luajithbtex --no-error-if-no-format --no-error-if-no-engine=luajithbtex,luajittex,mfluajit --status-file=C:\Users\***\AppData\Local\Temp\rPSb0Dpak2\WW_dJvUHgX ...
I tried to continue anyway with Regenerate fontmaps, and then tried again pdflatex on the minimal document. New error:
This is pdfTeX, Version 3.141592653-2.6-1.40.23 (TeX Live 2021/W32TeX) (preloaded format=pdflatex)
restricted \write18 enabled.
---! c:/texlive/2021/texmf-var/web2c/pdftex/pdflatex.fmt made by different executable version
(Fatal format file error; I'm stymied)
5. I tried again steps 3. and 4., but with "Run as Administrator". Same errors.
OK at this point I give up and really don't know what to do. Am I doing something wrong? For the moment I have to concur with this post: installation of TeX Live 2021 is an utter failure.
Here is the minimal latex file I used for testing (copy & paste):
\documentclass{article}
\begin{document}
test
\section{Section}
test
\end{document}
Found, that the download is not working because the system path to "cmd.exe" is not found. Therefore: open a cmd window and add the system path prior to starting the .bat file (set PATH=%PATH%;C:\Windows\system32)
I have a CUDA project in a .cu file that I would like to compile to a .mex file using mexcuda. Because my code makes use of the 64-bit floating point atomic operation atomicAdd(double *, double), which is only supposed for GPU devices of compute capability 6.0 or higher, I need to specify this as a flag when I am compiling.
In my standard IDE, this works fine, but when compiling with mexcuda, this is not working as I would like. In this post on MathWorks, it was suggested to use the following command (edited from the comment by Joss Knight):
mexcuda('-v', 'mexGPUExample.cu', 'NVCCFLAGS=-gencode=arch=compute_60,code=sm_60')
but when I use this command on my file, the verbose option spits out the following line last:
Building with 'NVIDIA CUDA Compiler'.
nvcc -c --compiler-options=/Zp8,/GR,/W3,/EHs,/nologo,/MD -
gencode=arch=compute_30,code=sm_30 -gencode=arch=compute_50,code=sm_50 -
gencode=arch=compute_60,code=sm_60 -
gencode=arch=compute_70,code=\"sm_70,compute_70\"
(and so on), which signals to me that the specified flag was not passed to the nvcc properly. And indeed, compilation fails with the following error:
C:/path/mexGPUExample.cu(35): error: no instance of overloaded function "atomicAdd" matches
the argument list. Argument types are: (double *, double)
The only other post I could find on this topic was this post on SO, but it is almost three years old and seemed to me more like a workaround - one which I do not understand even after some research, otherwise I would have tried it - rather than a true solution to the problem.
Is there a setting I missed, or can this simply not be done without a workaround?
I was able to work my way around this problem after some messing around with the standard xml-files in the MatLab folder. The following steps allowed me to compile using -mexcuda:
-1) Go to the folder C:\Program Files\MATLAB\-version-\toolbox\distcomp\gpu\extern\src\mex\win64, which contains xml-files for different versions of msvcpp;
-2) Make a backup of the file that corresponds to the version you are using. In my case, I made a copy of the file nvcc_msvcpp2017 and named it nvcc_msvcpp2017_old, to always have the original.
-3) Open nvcc_msvcppYEAR with notepad, and scroll to the following block of lines:
COMPILER="nvcc"
COMPFLAGS="--compiler-options=/Zp8,/GR,/W3,/EHs,/nologo,/MD $ARCHFLAGS"
ARCHFLAGS="-gencode=arch=compute_30,code=sm_30 -gencode=arch=compute_50,code=sm_50 -gencode=arch=compute_60,code=sm_60 -gencode=arch=compute_70,code=\"sm_70,compute_70\" $NVCC_FLAGS"
COMPDEFINES="--compiler-options=/D_CRT_SECURE_NO_DEPRECATE,/D_SCL_SECURE_NO_DEPRECATE,/D_SECURE_SCL=0,$MATLABMEX"
MATLABMEX="/DMATLAB_MEX_FILE"
OPTIMFLAGS="--compiler-options=/O2,/Oy-,/DNDEBUG"
INCLUDE="-I"$MATLABROOT\extern\include" -I"$MATLABROOT\simulink\include""
DEBUGFLAGS="--compiler-options=/Z7"
-4) Remove the architectures that will not allow your code to compile, i.e. all the architecture flags below 60 in my case:
ARCHFLAGS="-gencode=arch=compute_60,code=sm_60 -gencode=arch=compute_70,code=\"sm_70,compute_70\" $NVCC_FLAGS"
-5) I was able to compile using mexcuda after this. You do not need to specify any architecture flags in the mexcuda call.
-6) (optional) I suppose you want to revert this change after you are done with the project that required you to make this change, if you want to ensure maximum portability of the code you will compile after this.
Note: you will need administrator permission to make these changes.
So I downloaded and installed Microsoft Accelerator v2 to use ParallelArrays. I have referenced it in my project but when I try and execute the code from the module in a script file I get:
"The namespace 'ParallelArrays' is not defined
I have followed the instructions on this post:
Microsoft Accelerator library with Visual Studio F#
I've added a reference to the managed version "Microsoft.Accelerator.dll" to my F# project and then added the native "Accelerator.dll" as an item in my solution and set it's 'Copy To Output Directory' to Copy Always.
Still getting the FSI error and inline error in my script file on the '#load ...' line, however the solution builds fine, and no error in the module file.
Any ideas on what I'm missing? I'm sure it's something stupid.
Thanks,
Justin
UPDATE
I tried mydogisbox's advice, which got rid of the error above, but now when I run the code in the .fsx file I get this error instead:
--> Referenced 'F:\Work\GitHub\qf-sharp\qf-sharp\bin\Debug\Microsoft.Accelerator.dll' (file may be locked by F# Interactive process)
[Loading F:\Work\GitHub\qf-sharp\qf-sharp\MonteCarloGPU.fs]
error FS0192: internal error: F:\Work\GitHub\qf-sharp\qf-sharp\Accelerator.dll: bad cli header, rva 0
UPDATE 2
So the bad header error has dissapeared, but now I get this instead:
Microsoft.ParallelArrays.AcceleratorException: Failure to create a DirectX 9 device.
at Microsoft.ParallelArrays.ParallelArrays.ThrowNativeAcceleratorException()
at Microsoft.ParallelArrays.DX9Target..ctor()
at <StartupCode$FSI_0002>.$FSI_0002_MonteCarloGPU.main#() in F:\Work\GitHub\qf- sharp\qf-sharp\MonteCarloGPU.fs:line 14
Stopped due to error
I found this thread on MSDN however the answers proposed as fixes on that thread barely even relate to the question.
http://social.msdn.microsoft.com/Forums/vstudio/en-US/98600646-0345-4f62-a6c5-f03ac9c77179/ms-accelerator?forum=csharpgeneral
My Direct X version is 11, and I imagine that will suffice, however I tried installing DX9 however, it tells me that a newer version is detected therefore cant install.
There are special directives for referencing dlls from fsi. The #load directive loads the .fs file only. You need to use the #r directive to reference the file. You can either use the full path of the file or you can use #I to include the path to the file. More details here. Keep in mind that fsi is completely independent of your project, so all references in your project must be duplicated in fsi for it to access the same types.
I'm trying to resurrect an old (1999 or earlier) project written in Scheme (PLT-Scheme, using the mzscheme interpreter (?) commandline tool). To make the matters worse, I don't know Scheme, or Lisp (in fact, I want to learn, but that's another story).
I have the source code of the project at:
github.com/akavel/sherman
Now, when running the code, it bails out with an error message like below:
Sherman runtime version 0.5
Hosted on MzScheme version 52, Copyright (c) 1995-98 PLT (Matthew Flatt)
reference to undefined identifier: list->block
(I've tried PLT-Scheme versions 52, 53, 103, 103p1. Earlier versions don't allow mzscheme -L option, which is referenced in the sherman.bat script used in the project. Later versions also have some more serious problems with the code or options.)
The difficulty is, that from what I see, list->block actually is defined - see: collects/sherman/BLOCK.SS line 48. So, what is wrong?
To run the code, I perform the following steps:
Download PLT-Scheme v. 103p1 (from the old versions download page - first closing the "PLT Scheme is now Racket" banner) - for Windows, use: mz-103p1-bin-i386-win32.zip.
Unzip (e.g. to directory c:\PLT).
Copy c:\sherman\collects\sherman directory with contents to: c:\PLT\collects\sherman (where c:\sherman contains the contents of the github repository).
Run cmd.exe, then cd c:\sherman.
set PATH=c:\PLT;%PATH%
sherman.bat run trivial.s
this command is in fact, from what I understand, equivalent to:
(require-library "runtime.ss" "sherman")
(parameterize ((current-namespace sherman-namespace)) (load "trivial.s"))
(current-namespace sherman-namespace)
After that, I get the error as described above (MzScheme version would be reported as 103p1 or whatever).
Could you help me solve the problem?
EDIT 2: SOLVED!
To whom it may concern, I've added a fully fledged "How to use this project" instruction on the project page, detailing the solution to the problem thanks to soegaard's help.
In short:
copy trivial.s trivial.rs
rem (the above is workaround for problems with 'r2s.exe < trivial.r > trivial.rs')
sherman.bat compile trivial.rs
sherman.bat run trivial.zo
rem (or: sherman.bat run trivial.ss)
Not an answer, but a few notes too big for a comment.
1. Sanity Check
The error message says list->block is undefined.
Make sure that the code in block.ss is run, by
inserting (display "block.ss is loaded!") in block.ss
just to make sure, the code is run.
2. Random Thoughts
The file blocks.ss begins with:
(require-library "functios.ss")
(require-library "synrule.ss")
(require-library "stream.ss" "sherman")
The file "sherman/stream.ss" is in the repository,
but where is "synrule.ss" and "functios.ss" ?
Ah... This code is old! Here is a description of
how require-library worked. It lists functios.ss
and synrule.ss as part of MzLib.
http://www.informatik.uni-kiel.de/~scheme/doc/mzscheme/node158.htm
Let's check out how require-library worked:
When require-library is used to load a file, the library name and the
resulting value(s) are recored in a table associated with the current
namespace. If require-library is evaluated for a library that is
already registered in the current namespace's load table, then the
library is not loaded again; the result(s) recorded in the load table
is returned, instead.
So when the code in block.ss is run, the names are stored in a namespace. If the current namespace is the wrong one, when the code in block.ss is evaluated, it would explain you error message of list->block being undefined.
I am trying to migrate one of projects earlier in VS2008 to VS2010. On building I get the following error
C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(317,7): error MSB4094: "hdxBinding.idl;hdxBlinking.idl;HDXCommandObject.idl;hdxds.idl;HSCProcessStatus.idl;HSCSelectableWindow.idl" is an invalid value for the "Source" parameter of the "MIDL" task. Multiple items cannot be passed into a parameter of type "Microsoft.Build.Framework.ITaskItem".
On clicking this error, it takes me to the line Source ="#(Midl)" inside C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets file
A Code Snippet in Microsoft.CppCommon.targets file:
<ItemGroup>
<Midl Condition="'#(Midl)' != ''">
<MinimalRebuildFromTracking Condition="'$(BuildType)' != 'Build' or '$(ForceRebuild)' == 'true'">false</MinimalRebuildFromTracking>
</Midl>
</ItemGroup>
<PropertyGroup>
<MidlToolArchitecture Condition="'$(MidlToolArchitecture)' == ''">$(DefaultToolArchitecture)</MidlToolArchitecture>
</PropertyGroup>
<MIDL
Condition ="'%(Midl.ExcludedFromBuild)'!='true'"
Source ="#(Midl)"
AdditionalIncludeDirectories ="%(Midl.AdditionalIncludeDirectories)"
AdditionalOptions ="%(Midl.AdditionalOptions)"
ApplicationConfigurationMode ="%(Midl.ApplicationConfigurationMode)"
ClientStubFile ="%(Midl.ClientStubFile)"
CPreprocessOptions ="%(Midl.CPreprocessOptions)"
DefaultCharType ="%(Midl.DefaultCharType)"
DllDataFileName ="%(Midl.DllDataFileName)"
EnableErrorChecks ="%(Midl.EnableErrorChecks)"
ErrorCheckAllocations ="%(Midl.ErrorCheckAllocations)"
ErrorCheckBounds ="%(Midl.ErrorCheckBounds)"
ErrorCheckEnumRange ="%(Midl.ErrorCheckEnumRange)"
ErrorCheckRefPointers ="%(Midl.ErrorCheckRefPointers)"
ErrorCheckStubData ="%(Midl.ErrorCheckStubData)"
ExcludedInputPaths ="$(ExcludePath)"
GenerateClientFiles ="%(Midl.GenerateClientFiles)"
GenerateServerFiles ="%(Midl.GenerateServerFiles)"
GenerateStublessProxies ="%(Midl.GenerateStublessProxies)"
GenerateTypeLibrary ="%(Midl.GenerateTypeLibrary)"
HeaderFileName ="%(Midl.HeaderFileName)"
IgnoreStandardIncludePath ="%(Midl.IgnoreStandardIncludePath)"
InterfaceIdentifierFileName ="%(Midl.InterfaceIdentifierFileName)"
LocaleID ="%(Midl.LocaleID)"
MkTypLibCompatible ="%(Midl.MkTypLibCompatible)"
OutputDirectory ="%(Midl.OutputDirectory)"
PreprocessorDefinitions ="%(Midl.PreprocessorDefinitions)"
ProxyFileName ="%(Midl.ProxyFileName)"
RedirectOutputAndErrors ="%(Midl.RedirectOutputAndErrors)"
ServerStubFile ="%(Midl.ServerStubFile)"
StructMemberAlignment ="%(Midl.StructMemberAlignment)"
SuppressCompilerWarnings ="%(Midl.SuppressCompilerWarnings)"
SuppressStartupBanner ="%(Midl.SuppressStartupBanner)"
TargetEnvironment ="%(Midl.TargetEnvironment)"
TypeLibFormat ="%(Midl.TypeLibFormat)"
TypeLibraryName ="%(Midl.TypeLibraryName)"
UndefinePreprocessorDefinitions ="%(Midl.UndefinePreprocessorDefinitions)"
ValidateAllParameters ="%(Midl.ValidateAllParameters)"
WarnAsError ="%(Midl.WarnAsError)"
WarningLevel ="%(Midl.WarningLevel)"
TrackerLogDirectory ="%(Midl.TrackerLogDirectory)"
MinimalRebuildFromTracking ="%(Midl.MinimalRebuildFromTracking)"
ToolArchitecture ="$(MidlToolArchitecture)"
TrackerFrameworkPath ="$(MidlTrackerFrameworkPath)"
TrackerSdkPath ="$(MidlTrackerSdkPath)"
TLogReadFiles ="#(MIDLTLogReadFiles)"
TLogWriteFiles ="#(MIDLTLogWriteFiles)"
ToolExe ="$(MIDLToolExe)"
ToolPath ="$(MIDLToolPath)"
TrackFileAccess ="$(TrackFileAccess)"
AcceptableNonZeroExitCodes ="%(Midl.AcceptableNonZeroExitCodes)"
YieldDuringToolExecution ="$(MidlYieldDuringToolExecution)"
>
</MIDL>
Can somebody please tell me whats going wrong here. This is driving me crazy!!!!!!
Got a similar error today on a project that I am converting to VS2010. I don't have a good solution to the problem yet, but I have a workaround. In my case, the project contained 2 idl files. Call them A.idl and B.idl. A.idl is the main idl for the project. It includes B.Idl. The error I received was:
error MSB4094: "A.idl;B.idl" is an invalid value for the "Source" parameter of the "MIDL" task. Multiple items cannot be passed into a parameter of type "Microsoft.Build.Framework.ITaskItem".
It seems that the build system searched for all idl files in the project and made a single call to the MIDL compiler with all of them even though that was bound to fail. I don't know why VS2010 does that and earlier version didn't (or maybe earlier versions of MIDL could handle multiple inputs).
The workaround: grab the MIDL arguments off of MIDL Command Line page of the project's properties. Then run MIDL by hand in a VS2010 Command Prompt window using those args. In my case, since A.idl includes B.idl, I only needed to run one MIDL command:
MIDL options-copied-from-project-properties A.IDL
It looks like you have multiple idl files in your project (hdxBinding.idl, hdxBlinking.idl, etc.). So the same trick might work for you.
Good luck
I ran into this issue trying to build the DataMonitor example from the TMG SDK with Visual Studio 2010. The problem from what I can tell is the MIDL > Output settings in the project - the Header File, IID File, Proxy File, and Type Library were set to "DataMonitor...", which was forcing those settings to be applied to all included IDL files (and not just the project's generated one).
Changing those settings to use %(Filename) instead and the project built fine.
When there are multiple IDL files in the project I converted from VS 2008 to VS 2010, I got this error. Since one IDL I had was included in the other. I disabled building of the included IDL file and it resolved this error.
These errors prop up when migrating to VS2010 as the .idl file properties are not migrated by VS2010 migrator. I got a similar error and resolved this by manually adding these parameters from to VS2010. Once done you will be able to get rid of these build errors.
I run into the same problem as well. The fix was (very confusing) remove empty in the vcxproj file. I run out of time and have not got to the bottom of why it helps - defining not empty HeaderFileName fixes the problem as well, other empty elements do not cause this problem (e.g. DllDataFileName).
If you want to reproduce bug or process of my investigation just create hello world and add two idl files. It should work. However if you add ItemGroupDefinition with Midl.HeaderFileName it should start failing. One wild guess is that it has something to do with batching of tasks (working example calls MIDL task for each file separately).