I've been using a macro library to find and compile my macro codes until recently, where SAS cannot load the macro.
The code I use is:
options mautosource sasautos=MacLib;
filename MacLib "C:\Users\your.name.here\Documents\Macro_Library";
My macro is saved in the file path above as MacroOne.Sas and I try to run a command in SAS
%MacroOne;
For some reason it is just not compiling anymore, any help?
It was the wrong way around
filename MacLib "C:\Users\your.name.here\Documents\Macro_Library";
options mautosource sasautos=MacLib;
Related
sas error 180-322: statement is not valid or not used in proper order.
#echo off
#echo off
rem/\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*/
call d:/opt/----
please give me the soluion to resolve the error of #echo off
The code you have listed is DOS command line code, not SAS, as Tom mentioned. It is for a .bat or .cmd file. Calling it direct in SAS is not going to work. You can create a file with it and name that file .cmd or .bat then execute it via the SAS X command.
However, tell us what you are trying to do and we might be able to help. Use PowerShell vs DOS command language, anyways.
I use C-SPY macros for automated testing. For this purpose I load a startup macro file and it loads additional macro files using the following code:
execUserSetup()
{
__registerMacroFile("$_ENVVAR_$\\macros-1.mac");
__registerMacroFile("$_ENVVAR_$\\macros-2.mac");
...
}
This works like a charm when I run the startup macro from within the IAR Embedded Workbench.
But what I really want to do is running the tests with CSpyBat.exe. There I specify my startup.mac using the option --macro startup.mac.
The files macros-1.mac and so on won't be found then. Instead I get error messages for the macro files (with garbage file names, see below):
ERROR: Could not open macro file: #۸0ٸ`ٸ#2#u
If I use the pathnames without the environment variables, everything is okay.
What am I doing wrong?
The answer is: The workbench supports expanding environment or project variables, but CSpyBat doesn't. So told me IAR support. Also they gave me the following pointer:
See 'C-SPY Debugging Guide' - "Using C-SPY in batch mode", "INVOCATION SYNTAX", page 492:
Note: In those cases where a filename is required—including the DLL files—you are
recommended to give a full path to the filename.
As part of a build process, I need to take an environment variable defined by a batch script and use it as a constant within the code at compile time.
For example, say I have defined an environment variable named BUILD_VERSION and set it to 1.0.0, when compiled I want 1.0.0 to be baked into my code. EG:
Batch file:
set BUILD_VERSION = 1.0.0
; call vs compiler
C++ File:
const std::string build_version = BUILD_VERSION // Which will result in "1.0.0".
How would I go about doing this?
In the end I followed txchelp advice and added a /D flag into the Command Line -> Additional Options section of the project properties to declare the environment variable as a preprocessor definition.
It looked something like this:
Then in the batch script that started the build:
set SVN_BUILD_VERSION=1.0.0
And finally to extract it as a string within the source code:
#define STRINGIZER(arg) #arg
#define STR_VALUE(arg) STRINGIZER(arg)
#define BUILD_VERSION_STRING STR_VALUE(BUILD_VERSION)
// ...
const std::string version = BUILD_VERSION_STRING; // Results in "1.0.0".
You can use a prebuild step (I suppose you are on Visual Studio) which will run script which will get this environment variable value, parse C++ source file and change the value
"1.0.0.0" to "1.0.0.1".
Such substitution can be conveniently done by awk.
A VERSION_INFO resource could be a good way go.
The version info so embedded can be inspected by right-clicking the executable and checking its properties.
To do that at the command line:
Redirect output from a batch file to an [.rc] file defining the resource.
Compile the resource using rc.exe.
Embed the resulting .res file by simply passing it to the linker.
Within Visual Studio it might be more complicated.
In a C++ iOS project (or any other Mac OS), is there a simple way of making a value available both to the Info.pList settings, and to the code in the form of a preprocessor macro?
Ideally, I would like to have something like this
C++ code:
#define MY_VERSION_STRING "1.0"
Info.pList
CFBundleVersion: ${MY_VERSION_STRING}
Or alternatively, is there a way of getting values from the .pList in c++? (Without manually parsing the .pList as xml.)
Probably not the best solution, but you could use the /usr/libexec/PlistBuddy utility in a build script to generate a .h file containing a define with a value extracted from the plist.
To output a value from a plist:
/usr/libexec/PlistBuddy -c 'Print :Path:To:Key' filename.plist
I know this has already been answered, but I'll add my two cents for posterity. As Richard mentioned above, Xcode has a couple of options for preprocessing Info.plist files -- the most relevant to the current question are "Preprocess Info.plist" and "Info.plist Preprocessor Prefix File".
If your version information is defined in, say ver.h, you can include ver.h as the prefix file and refer to the version macro directly from Info.plist.
This is all readily doable without involving PlistBuddy at all, entirely using build settings.
you create a user defined build setting for your project/target either in the Xcode UI or if you're familiar with xcconfig files you can define it there in a completely textual = form.
you create your setting MY_VERSION_STRING with a value of 1.0 as your build setting either in Xcode or in an xcconfig file.
in your Info.plist your CFBundleVersion line would have a value of ${MY_VERSION_STRING}
you turn on Info.plist preprocessing
lastly, make use of GCC_PREPROCESSOR_DEFINITIONS build variable. for that build setting you can specify a value of MY_VERSION_STRING=${MY_VERSION_STRING} which will result in your defined and shared build setting definition available in to your c/c++/obj-c code as if you had created it as a #define
Property list can also store arrays or some binary data. How do you represent that? It is very domain-specific. So if you know exactly how do you want each type to be represented in C++, you have to either parse plist file and generate C++ code, be that preprocessor directives, or some code defining arrays, enums etc. There are PlistBuddy and plutil tools available, but they probably won't be much of a help. The easiest way for me would be to use perl, see Using Perl to Manage Plist Files for details.
Good luck!
In case anyone wants to do the same thing, this is the script I added to the target before the compilation phase:
VERSION=`/usr/libexec/PlistBuddy -c 'Print :CFBundleVersion' Info.plist`
echo "#define VERSION_STRING L\"$VERSION\"" > Version.h
If you use #define..., you shoud use in the .plist key, MY_VERSION_STRING, and not ${MY_VERSION_STRING}. This works too with the "Info.plist Preprocessor Prefix File". In both cases don't forget to set "Preprocess Info.plist File".
I am generating VisualStudio C++ project files from a build system.
The compiler options in the XML for the project file are in a different format from the command line options specified for the compiler.
I need to get from command line options for cl.exe to the project file options for the VCCLCompilerTool.
1 - Is anyone aware of an open source script designed to do exactly this?
2 - If one removes all the options from the XML and puts all the command line options into the "AdditionalOptions" attribute, will it filter these or is everything put in there added to the command line verbatim ? will the "AdditionalOptions" overide the defaults if there are options present from in the UI ? ( I havn't written a proxy cl.exe to test what it actually gets in this case :)
Thanks!!!!
One solution could be to use Property Sheets (vsprops). You could generate a vsprops file for every option you intend to use (this is done from the property sheet editor in visual studio). Then in your generated project file reference each property sheet that contains the option(s) you intend to use in the InheritedPropertySheets seciton. We do something similar by grouping various options together into related propery sheets. For example we use the following sets of property sheets:
ARMASM.rules
C++ Standards Compliance.vsprops
Debug Program Database.vsprops
Debug.vsprops
Multi-Threaded Debug Libraries.vsprops
Multi-Threaded Release Libraries.vsprops
Optimize for Size.vsprops
Platform Directory.vsprops
Release.vsprops
Static Library.vsprops
Strictest Warnings.vsprops
Win32.vsprops
WinCE.vsprops