I want to know if it's possible to pass ISCC option if I compile my script within the Inno Setup Compiler IDE (optimal in Inno Script Studio).
I found this question which says I should do something like
#ifndef myDefine
#define myDefine "value"
#endif
I've already tried that because of the answer of my other question.
What I try to achive in the IDE is:
ISCC /DPHASE=test "D:\foo\bar.iss"
So is there an option in the IDE where I can pass preprocessor parameters?
No, there's no other way than to define some meaningful defaults in your .iss file.
If you do not want the value to be directly in the main .iss file, you can import them from other file using
#include "Defaults.iss"
Maybe conditionally:
#ifexist "Defaults.iss"
#include "Defaults.iss"
#endif
See Inno Setup Preprocessor: #include.
Note that the Inno Setup IDE does not actually launch the iscc.exe binary for the compilation. It has the "iscc" linked into itself. Were it launching an external process for the compilation, it would be possible to somehow inject the parameters.
Related
I'm working on a CMake-based project that contains both C++ and CUDA source files, and has some headers meant to be included by both languages.
For these header files, I'd like to see the result of highlighting and syntax checking as close as possible to what NVCC, the CUDA compiler, would see, so for example, I'd like to have the preprocessor symbol __CUDACC__ be defined.
It's important to me that CMake does not have such a symbol defined, because it's really an internal symbol of the NVCC toolchain that I need for syntax-checking purposes.
I've tried "Tools->C++->Additional preprocessor directives" and it seems to have no effect. I've also tried a file named CMakeLists.txt.config which seems to have no effect either.
I'd love a suggestion for this.
To reiterate, I'm looking for a way to set a define (CPP symbol) visible to to the syntax-checking system only.
After further digging I found an attribute specific to the Clang analyzer that is defined during the analysis performed for syntax checking but not during compilation.
Note that this is purely because my project compiles with GCC, while QT Creator's syntax checking runs through Clang.
// GCC and NVCC don't have __has_feature(), so we provide a fallback
#ifndef __has_feature
# define __has_feature(x) 0
#endif
#if __has_feature(attribute_analyzer_noreturn)
# define IN_CLANG_ANALYZER 1
#else
# define IN_CLANG_ANALYZER 0
#endif
This allows a clumsy hack as follows, which may or may not be useful, depending on one's needs. Pretty much the idea is that much like you'd
have Clang observe your code even if you compile with GCC, this achieves
something similar for files inteded to be used with NVCC.
#if IN_CLANG_ANALYZER and !defined(__CUDACC__)
# define __CUDACC__
# include <cuda_device_runtime_api.h>
# include <optix_device.h>
#endif
However the substantial problem remains that when compiling with Clang, all the above falls flat on its face, because clang++, the compiler, also defines the same feature as enabled.
What's needed to fix this is some kind of macro defined in the analyzer but not in Clang, and so far I've found none like this.
At first I had hoped __clang_analyzer__ would fit this need,
but according to my version of Qt Creator (6.0.2) the macro is not defined
during syntax checking, so we're back to square one.
Enabling PREfast static analysis checks in an existing project I have yields many instances of the following:
C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\um\WindowsNumerics.inl(2375) : warning C6101: Returning uninitialized memory ‘*scale’. A successful path through the function does not set the named Out parameter. Annotate this function with Success(return) if returning FALSE indicates failure.: Lines: 2375, 2379, 2381, 2383, 2375
This may be triggered by including any of the following headers:
#include <winrt/Windows.Storage.FileProperties.h>
#include <winrt/Windows.Media.Capture.h>
#include <winrt/Windows.Storage.h>
#include <winrt/Windows.Foundation.Collections.h>
#include <winrt/Windows.Data.Json.h>
but all instances I've seen so far seem common to WindowsNumerics.inl.
This prevents us from enabling PREfast on winrt projects without adding specific suppressions in our code as a workaround. Should we expect winrt headers to pass these checks? Will this be addressed in a future release?
This seems to be a case of the header missing _Success_(return != false) annotation on the invert and decompose functions.
This bug is still present in the latest public Windows SDK (22000).
I'll see if I can find the owner to file a bug for a future Windows SDK release.
You haven't mentioned which toolset you are using, but you should take a look at /external switch.
Im getting several warnings saying I have inconsistent dll linkages despite me classifying the header of my dll like so:
#ifdef MY_ENGINE_EXPORTS
#define ENGINE __declspec(dllexport)
#else
#define ENGINE __declspec(dllimport)
#endif
It works fine to get rid of the errors when I add MY_ENGINE_EXPORTS to the preprocessor definitions but I was under the impression that this should be done automatically on build/export. Am I wording it wrong? I included an underscore because the project is 2 words e.g "my engine". I've tried it as both MY_ENGINE_EXPORTS and MYENGINE_EXPORTS but neither seems to work.
As I say I can just add it to preprocessor definitions but it's bugging me why it doesn't behave as it should.
I figured it was a predefined macro that the environment created for dll projects
Yes, that does happen when you use the Win32 Project template to get the DLL project started. The wizard will automatically add the PROJECTNAME_EXPORTS preprocessor definition for you.
The wrinkle is that it cannot use a space in the symbol so it cannot use "MY PROJECT_EXPORTS". It will drop the space and make it MYPROJECT_EXPORTS. Which doesn't match with the one you used, MY_PROJECT_EXPORTS. Nothing a quick Edit + Replace can't fix of course.
In my project I use different flags to run different code when dealing with multiple targets. Something like
#ifdef MY_FLAG
//do this
#else
//do this other
#endif
Now I'm on my way to take some code to an external library, but I don't want to compile different versions of the library for each flag, so the question is:
Is there a way to pass something like arguments that tells the library (or framework) from outside which code should run in a "global" manner?
What you're doing with #ifdef is establishing which code the compiler can see. So you're going to have to compile different versions for each flag, as libraries are linked against but are already compiled. I guess the question is more what you do with those on disk.
You can store multiple CPU architectures into a single static library. So any of those flags that are merely to do with whether you're targeting ARMv7, ARMv7s or i386 can be handled with a single library.
For the others you're probably going to have to produce different libraries. However that'll just be a matter of the shape of the disk footprint — you can use the project settings of any project you link against your libraries so that it links to a different version of the library depending on the build configuration.
One option is to have the framework provide some sort of initialization method or function that the user of the framework can call. This would tell the framework what "mode" it should run in. The client of the framework could call this at app startup.
I've been searching for a way to dynamically compile AIR apps on the go.
Specifically, I'd need the title of the program and a couple variables changed on compile. I'll be creating hundreds, if not thousands, of versions of what is essentially the same program so I'd like to avoid doing it by hand :)
Is this possible with AIR? If not, could I do it with something like Java?
Yes, this is possible using the mxml compiler in the Flex sdk. It requires some knowledge of a build tool like ant or maven.
Automate the build process with apache ant or maven.
Use Actionscript compiler directives to define place holders for your variable data in your code.
Modify the build scripts to compile the build, and pass in the variable data as compiler arguments
I've done this with ant build scripts to include a timestamp and other info in the app's version string. Here's example with a timestamp...
1. Define variables in the compiler argument options for your project
The syntax is:
-define=NAMESPACE::VARIABLE_NAME,'variableValue'
For example:
-define=APPDATA::TIMESTAMP,"xxx"
This is what a developer would put in their IDE. When they compile their apps, the version string will have "xxx" in it. When the automated build script compiles the app, it passes in an actual timestamp using a similar argument.
2. Reference the variable in your code.
I'm using it as a String, but you can do Boolean and I assume the other primitive types.
public var appVersion:String = "MyApp " + APPDATA::TIMESTAMP;
You can conditionally compile code into the SWF with booleans:
-define=CONFIG::DEBUG,true
Now wrap code blocks with this compiler directive, and if true it will be compiled into the swf:
public function something():int
{
var a:int = 1;
CONFIG::DEBUG
{
a=2;
}
return a;
}
While this is pretty handy, I recommend only using compiler directives for things you really need to do at compile time, and not for general configuration :)
Resources:
Using conditional compilation
mxmlc compiler options
flex ant tasks
flex mojos maven plugins