I am building a project on Github written in Objective-C. It resolves MAC addresses down to manufacturer details. The lookup table is currently stored as text file manuf.txt (from the Wireshark project), which is parsed at run-time, which is costly. I would prefer to compile this down to archived objects at build-time, and load that instead.
I would like to amend the build phases such that I:
Build a simple compiler
Run the compiler, parsing manuf.txt and outputting archived objects
Build the framework
Copy the archived objects into the framwork
I am looking for wisdom on how to achieve steps 1 and 2 using Xcode v7.3 as Xcode provides only a Copy Files phase or a Run Script phase. An example of other projects achieving similar goals would be inspiring.
I suspect that what you are asking is possible, but tricky. The reason is that you will need to write a bunch of class files and then dynamically add them to the project.
Firstly you will need to employ a run script phase to run various tools from the command line to parse your file and generate a number of class files from it. I would suggest looking into various templating engines. For example appledoc uses moustache templates to generate API documentation files. You could use the same technique to generate header and implementation files.
Next, rather than generating archived objects an trying to import into a framework. I think you may be better off generating raw source code, adding it to a project and compiling into a framework. Probably simpler in the long run.
To automatically include the generated code I would look into (which means I haven't actually tried this :-) adding a folder reference to the project rather than an Xcode group. Folder references are an option in the 'Add files to ...' dialog.
Folder references refer to a directory and automatically add the entire contents of that directory to a project. So you can use one to point to the directory where you have generated the source code. This is a much better option than trying to manipulate the project or injecting things into an established framework.
I would prefer to parse the file at runtime. After launch you can look for an already existing output, otherwise parse it one time.
However, I have to do something similar at Objective-Cloud. I simply added a run script build phase and put the compiler call into it.
Related
I am writing a very basic library in VB.NET
The library just contains classes and modules.
Now in built output I see this files
Application.Designer.vb
Application.myapp
AssemblyInfo.vb
Resources.Designer.vb
Resources.resx
Settings.Designer.vb
Settings.settings
Since I've seen other libraries with only AssemblyInfo.vb file, I was wondering if I can delete the rest.
What is the minimum of files I need here for the lib to work correctly, since I don't have any ressource or setting?
All the files you listed are necessary for a vb.net library project. And these files are generated (in My Project folder) when the project created not the build output files. So you need to keep all the files you listed in order to develop and build your project locally.
And for the files of build output, you can add these files in .gitignore.
When you create a project in VS, you select a predefined template that dictates what gets created. People often become accustomed to seeing the superfluous objects that a given template creates and assume that those objects are mandatory and must be there, However, much of it is not needed.
There is also the Empty Project template (the exact name of this template varies depending on the VS version used).
In VS2017, selection of the template would look like this:
This is a bare-bones project and the Solution Explorer will look like this:
As you can see, there are no pre-loaded references. You will need to add them yourself. About the only thing defined in this template is that you are using the VB language; This project starts out as a WinForm type, so go to the Project Properties->Application tab and change the "Application type" to "Class Library" since you want to create a library.
You may find it useful to start with an Empty Project and add the stuff you normally use and then export the project as new template (in VS2017: Project Menu->Export Template). For more on creating termplates, see: Creating Project and Item Templates
Edit: I just realized that I did not answer your real question about deleting the unused items. I just did a test case and deleted the items under MyProject. I received an error on deletion, but doing a clean/rebuild allowed me to proceed without issues. I would recommend that you backup the project before attempting this on an existing project, but I saw no long term issues in deleting unneeded objects from MyProject.
Is there any way to make CMake "forget" about a file in the dependency tree? My original problem (to avoid the XY situation) is the following: I want to timestamp the build of a set of tools which have complicated dependencies among them and to other tools. Right now, I want to use a pure timestamp, but later I might want add some info from the repository (SVN). Whatever system I end up implementing needs to have the following characteristics (my "X"):
No unnecessary rebuilding: the executables should not be rebuilt on every make if the only change would be the timestamp.
Update on any change: if any tool is going to be rebuilt or relinked, either by changes to its code or to one of its dependencies, the timestamp needs to be updated.
My current solution goes along the lines of creating a custom command+target that invokes CMake at make time (so the command calls CMake itself with -P script.cmake) to generate a timestamp.h file. The main files of my tools would include that file, and the projects would depend on the target so that it gets rebuilt first.
However, this has its drawbacks: if I do update the timestamp file on every call to make, then CMake's dependency scanner would know about that file even if I do not list it as an explicit dependency of my tools. Thus, every make would trigger at least a recompilation of the respective "main" files and the corresponding relink. With tens of tools, this means slowing down the build when I may be working on just two or three of them at once.
So, I was thinking that my solution would be to somehow make CMake forget about that file when building its dependency tree for the "main" file of each tool. I would keep the dependency on the custom target that does depend on the file, so that it would be regenerated first on each call to make. However, the build tool would not consider that file as relevant to determine whether it is necessary to actually rebuild each individual tool. Thus, tools only with other changes would be rebuilt (satisfying my first criterion), and any change that causes a rebuild of a tool would obviously use the version just generated (fulfilling the second criterion).
To my chagrin, I have not found a way to make the dependency scanner forget about this file, so my solution cannot be put to use. How would I go about doing such a thing? Is it even possible, or is it completely the wrong way to go about this? I am using CMake 3.4, and my code is currently C++, but I would like a solution that did not rely on C/C++ specifics, since I have a different project (written in Fortran) in which I would also like to have build timestamping.
I've had almost the same problem than you are. Simply solved by pushing the timestamp header file into standalone target containing only this header generator command. After that you have several choices:
1.. Exclude that project from the build by the IDE you are using. For example, for the Visual Studio you can do it by several ways:
1.1. Project->Project Dependencies...->uncheck project with that header (not always works: Error while removing project dependency in VS2010)
1.2. Build->Configuration Manager...->uncheck project with that header
2.. Create an environment variable and use the condition with that variable around the add_dependencies command in the CMakeLists.txt file.
3.. Generate 2 standalone solutions through the cmake generator with included and with excluded add_dependencies in the CMakeLists.txt file.
I've used particulary [1.2]. When i need build and debug, then i uncheck the dependecy. By default, dependecy always checked, so there is no problem to miss timestamp build for a build server.
Note:
The timestamp header will be included in all projects you want to include that header (for example, through the add_library and add_executable) and you still can observe it in the IDE under a project item menu even if a project depends on the timestamp project indirectly. This is useful if you don't want to search for the timestamp project with the header to open it from there and want to open it from any project which has included that header.
So, in case of removing the timestamp header from the add_library or add_executable you won't have that opportunity.
I am new to Android Studio and trying to understand how it works. I have a project which is a mixed code base (C++ and Java) and trying to convert that to an Android Studio project.
As of now, I am building my app from command line because my app is currently not using any IDE, it is made up of multiple folders. I was wondering if I should be structuring my project such that every module creates a .so file? In another words should I have:
One module and multiple folder under it
Multiple modules
Does every module create one .so file or multiple .so files?
This depends on the size and complexity of your project. One advantage of having multiple shared libraries (.so files) is that if you make binary-compatible changes in one area of the codebase, you don't have to recompile your entire project. You can just rebuild the module which you made changes in, and the dependent modules will link to the updated library.
If your project is quite large and rebuilding everything takes a long time, this can be a big timesaver. If you want to be able to reuse certain modules in other projects without having to pull in all the code from this project, it would make sense to separate into modules.
Splitting your C++ code into multiple modules does add some complexity to the build (and the syntax to specify C++ builds keeps changing on top of that), so you'll want to take that into account when you decide.
Is there any way to get the number of classes in a project or the complete workspace in Xcode?
A simple way to get a rough idea for a project is by checking the Compile Sources section of the project's Build Phases. The compile sources will list all source files (.m, .swift) and doesn't include any headers.
Assuming roughly one class per source file, this will give you a ballpark idea of how many classes there are in your project at a glance. Note that this doesn't include any embedded projects or frameworks.
You could use cloc which can also be installed via Homebrew: brew install cloc.
Cloc is an open source command line tool for counting lines of code, but it also provides the count of files grouped by file type. The simplest form is cloc <path-to-your-project-dir> but the output can be configured by parameters.
A more complex solution (IMHO too complex) is, using Sonarqube with an Objective C plugin. Sonarqube has a nice interface and many functions, but just for counting classes, it's way to much.
There is code that I want to include in most of my projects. Things like AFNetworking, categories for CoreData and unit testing, etc.
It seems logical to include all of these in a static library, and then use it in each project. I've noticed though, that many third-party libraries (like AFNetworking, and it's predecessor ASIHTTP) are included in projects by copying over all of their source files and then manually linking the necessary libraries to the project target.
This seems to me like the easiest way. It took a fair amount of time to figure out how to include an existing static library into a project. Even after I knew how, it still seems like a pain to do it for every new project. Also, the header search paths that you specify are to a local directory with the static library's files. Wouldn't it be easier, and is there a way, to copy the static library's files into the project? This is the same idea as including the class files directly like most libraries seem to do already, but it would be more organized because everything would be lumped into one library project, instead of having class files everywhere and having to include every one of them.
Static libraries feel like they should be the right way to go. Make a library that can be used with all projects that includes classes that every project will need. Makes sense. I am just conflicted because it seems like the right way to go is to leave everything out of a 'formal' library, and just copy over all of the class files instead.
I guess I am just looking for what experienced developers find to be the best option.
I would be among the first to admit that the process of referencing a static library in Xcode is not entirely intuitive. However, using a static library is the best option, without a doubt.
The main reason is maintainability: when you copy source code of a library to many places, you must remember to update all of them to the latest code when you upgrade to the next version of the library. This may be a rather error-prone process, especially when the underlying library source changes significantly (e.g. new files are added, old files are renamed, etc.)
There's a halfway solution - make an XCode project that builds your static library from source and put that into a shared repository (ie.. git submodule etc) which is included from each project's main repository.
Each of your projects would include this submodule and project. Then they get the latest source code each time they pull that submodule. If you set this up as a build dependency it will build a static library the first time you build and then XCode is smart enough just to include it each subsequent build so you get the benefit of fast build times.
You also get the advantage of having the source right there for stepping though / debugging.
If it's in a separate XCode project and a new version of a library adds or removes a source file you would only need to change that shared project - all your individual projects wouldn't change at all.
What about using CocoaPods? This tool does exactly what you want in a declarative way: you have a file (Podfile) where you declare your dependencies, and the tool downloads all the dependencies and builds a static library that gets added to your project.
I would agree that static libraries feel like they might be the correct way to go for a number of reasons, but can also introduce some issues.
The positives would be creating an easy way to add a library to a project. Although not completely intuitive, it is rather trivial to add a static library to a project after one does it a few times. Add the files, add the search path, done. This could also be useful in certain source control situations. Also, updating a library may be easier.
I think the real problem here is for the open source community. By including, say AFNetworking, for example, as a static library, you lose all access to the implementation files. This is a great feature of including source rather than a library. It lets you change code to how you see fit, and hopefully give back.