I am working on a project that has a number of modules that I'd like to apply access control constraints to. I'd also like to have my project contain additional documentation on the type signatures of each function.
I know that I can accomplish both of these tasks very easily via F# signature files. However, my project is large and contains many files, and I need a convenient way of generating a signature file for each one. I have been successful in generating individual signature files via command line compilations using the --sig compiler option, but I am stuck on how to add compiler options to Visual Studio's build routine.
Is there a convenient way, either via VS compilation options, or via some command line script, for me to create an F# signature file for every *.fs file in my project directory?
Thanks.
You can tell VS to pass arbitrary flags to the compiler upon build by right clicking on your project in Solution Explorer and clicking "Properties." Under the "Build" tab fill in "Other flags".
Specifying --sig:<Some path> (with support for msbuild-style $(Variable) settings) will auto-generate a single combined .fsi for your library.
Related
I am aware that bazel accepts both BUILD and BUILD.bazel as valid filenames.
The android tools seem to also have a BUILD.tools file.
In general, does bazel have any restrictions for a BUILD file's extension? For example, could i have BUILD.generated to delineate generate BUILD files from non-generated BUILD files?
The .tools extension is part of building Bazel itself. From the perspective of Bazel, it's just any ordinary file. It gets picked up here: https://github.com/bazelbuild/bazel/blob/bbc8ed16aee07c3ba9321d58aa4c0ffc55fa2ba9/tools/android/BUILD#L197
then eventually gets processed here: https://github.com/bazelbuild/bazel/blob/c816b89a2224c3c318f1228755ef41c53975f45c/src/create_embedded_tools.py#L74
For the use case you mention, one way to go about it is to generate a .bzl file with a meaningful name that contains a macro that you can call from a BUILD or BUILD.bazel file. That way you can separate the generated rules from manually maintained rules. This is similar to how generate_workspace works: https://docs.bazel.build/versions/master/generate-workspace.html
I have code for a VST plugin and need to port some of it to an iOS app.
I have tried building the OSX version and using the lib.a and it doesnt work. When I open the iOS version of it, Xcode shows that it is missing the tagret.
If I copy the code directly into Xcode with all the JUCE modules, and I set the header search paths, I get compilation errors on things like no such type for String
After this latest JUCE update, Xcode would give the same errors until I updated the JUCE file itself, so I think the JUCE build settings or configuration of the new version is doing something differently. How can I get this code into a different Xcode project, so that I can use it?
Can I compile it as a library and use the objects through the header?
JUCE is designed to be included in projects generated by the Introjucer / Projucer (the JUCE project management tool). Without this, the correct preprocessor definitions will not be set up.
If you really needed to include JUCE source code inside your program, you could manually set up these preprocessor definitions (take a look at the AppConfig.h header from a generated project to get an idea of how much work this will be), but you'd really be going against the normal "JUCE way".
Simply including the headers and linking against the library will not work without considerable effort, as the include structure is ... odd ... and there isn't any library to link against directly anyway (the generated projects contain all the JUCE source normally, so there's no need).
Adding the JUCE source files (i.e. .cpp and .mm) to be compiled in a project directly will result in compilation errors, as they need to be compiled in a very specific order which is mandated by the header file (the header files #include certain implementation files after setting up their dependencies).
In short, if you can at all I would advise generating the project with the Projucer and adding other source files in as you need them, rather than the other way around.
Background
I'm porting a small Windows application to iOS using XCode 6.2 as both the IDE and build platform. I have a workspace created, which I'm using to compile and build all the projects. I currently build every project except the actual iOS app as a dynamic library, and then embed it in the final app package on deployment.
The Problem
I'm currently hard coding relative paths in the projects. Stuff like ../../shared-headers - I really don't like doing this as I have to figure out this path per project, and I'd prefer to use something like props files in Visual Studio, which would let me do something like $(SHARED_HEADERS) in projects.
This makes the projects easier to maintain, and any dependency extremely obvious. It also makes it much easier to move projects when the need arises. What is the preferred method to do this in XCode?
EDIT: I'd like to stick with a Visual Studio-ish include structure. While Copying headers is a good way to manage some of the complexity, I do not prefer this method because it will add time to the build, and developers from Windows will not be expecting this.
I too was looking for the same thing, and i've just found it! using an xcconfig file!
Create a .xcconfig file either from xcode's file menu or just a simple text file, and add your entires like so:
PATH_TO_SOME_SDK = Volumes/DEV/Project
SOME_DEFINITION = 7
once you add that file to the project, you can add it (or different ones) to each configuration in the project's info panel under "Configuration".
the definitions along with their values will then appear in the project's build settings under "User-Defined", and will change dynamically as the value in the file changes.
you can then use the values in any other build setting like any other environment variable or macro:
$(PATH_TO_SOME_SDK)
for more info:
https://nshipster.com/xcconfig
https://medium.com/better-programming/working-with-xcode-configuration-files-398cfbe02b64
https://help.apple.com/xcode/#/dev745c5c974
better late than never...
:-)
In Delphi linker tab (project option), there is a "Map file" option. I need to know a way to use with $IFOPT to detect the option is specified when compiling in order to have certain codes to be compiled.
{$IFOPT MapFileOption.....}
{$ENDIF}
There is no way to test this from code using $IFOPT.
The reason for this is that the map file generation happens post-compile. It is a link time step. So, you can take compiled dcu files and link them into an executable, generating a map file at that point. You can do this repeatedly, choosing different map file options each time, using the same dcu files. So, at the point of compilation, it is not known which map file option will be used.
I suppose the easiest way to see this is to consider the code in the Delphi RTL. That is supplied to you in the form of dcu files compiled by the vendor. You can build your executable with detail map, and I build mine without. But we both used the same RTL dcu files.
I am testing an image capture library that sent over their code library as a regular header file and a file ending in a "*.a" extension. I am not familiar with using a file in this format and can't seem to find the right "magic" to search for.
What does this file extension stand for?
What if any extra steps are needed to get it integrated with my XCode project?
Maybe a bit more of theory can get you in the right track so you'll know how to search next time:
.a files are archives of object (.o) files. These object files are generally produced by an assembler, compiler, or other language translator; They contain machine code that is usually not directly executable, but are used by linker tools to generate an executable or yet another library by combining parts of these object files.
Another important thing you should know is that since these files contain machine code, they must have been compiled for the correct architecture you're targeting for (ex.: armv7, i386, etc). That can be the reason why sometimes you will be able build your project for one device but not to another if you don't have the right set of files for the targeted platform (e.g. iPhone simulator vs. actual iPhone).
It is also possible to have "universal binaries", which are files that in turn package together archives of object files (.a) for different architectures (e.g. using tools such as lipo), so that the same library file can be given to the linker for multiple architectures. Or, you may have a different linker configuration for each target (e.g. using conditional build settings in XCode). All of these files can be analyzed with certain tools (e.g. "file", "otool", "lipo -info", etc), and each has several parameters to play with. Debuggers will also check the symbols within these files for their own purposes.
When you drag the '.a' file to your project's directory within Xcode, you can notice that it will automatically add this file to the list of "Link Binary With Libraries" items under your target's "Build Phases".
Since the header files allows us to separate certain elements of a program's source code into reusable files, that commonly contain forward declarations of classes, subroutines, variables, and other identifiers that are needed for reference during the compilation step, it is common to have libraries provided as archives of compiled objects (.o) in ".a" files along with their respective headers. For instance, as soon as you include the headers files in your XCode project, the editor will provide auto-complete for these new functions.
Sometimes, you might also consider having the actual source code of the library instead of binaries inside your project as this * might * make debugging easier in case an unexpected behavior is happening inside that "library" package. Many times this is not an option though (when you have no access to the sources) when the binary distribution is made in purpose to hide implementation details (commercial libraries).
.a stands for archive. It is also known as a static library. I believe you should be able just to drag it and the header files into Xcode. Xcode should pick up the right thing to do from its extension.
Example, see appr. from 30 sec here
http://memention.com/ac3dreader/usage/quickstart.html
Another example from Google Analytics, under Setup
Drag GANTracker.h and libGoogleAnalytics.a from the SDK's Library directory into your new project.
https://developers.google.com/analytics/devguides/collection/ios/devguide