I am using Xcode as part of my build for OS X, but since it is not the only IDE used, files may be added from the file system directly.
As far as I can tell, there are two ways of adding folders:
Folder reference picks up all the changes on the file system but does not register any of the files as sources.
Recursive copy allows for the files to be built but I need to constantly maintain the file structure
I am wondering if there was a way to setup Xcode to build all of the files that are a part of the folder reference or failing that, if there is a quick script to automagically fix file system discrepancies.
I came up with proof-of-concept solution that works, but will require some work to use in production. Basically, I set up a new "External Target", which compiles all source files in a given directory into a static library. Then the static library is linked into the Main Application.
In detail:
Create a directory (lets call it 'Code') inside your project directory and put some source code in it.
Create a Makefile in the Code directory to compile the source into a static library. Mine looks like this.*****
Create an External Target (lets call it 'ExternalCode') and point it to the Code directory where your source and Makefile reside.
Build the ExternalCode and create a reference to the compiled static library (ExternalCode.a) in the Products area of your project. Get Info on the reference and change the Path Type to "Relative to Built Product".
Make sure ExternalCode.a is in the "Link With Binary Libraries" section of your main target.
Add the ExternalCode target as a dependency of your main target
Add the Code directory to your "User Header Search Paths" of your main target.
Now when you drop some source files into 'Code', Xcode should recompile everything. I created a demo project as a proof of concept. To see it work in, copy B.h/m from the 'tmp' directory into the 'Codes' directory.
*Caveats: The Makefile I provided is oversimplified. If you want to use it in a real project, you'll need to spend some time getting all the build flags correct. You'll have to decide whether it's worth it to manually manage the build process instead of letting Xcode handle most of the details for you. And watch out for paths with whitespace in them; Make does not handle them very well.
Xcode's AppleScript dictionary has the nouns and verbs required to do these tasks. Assuming your other IDE's build scripts know what files are added/deleted, you could write very simple AppleScripts to act as the glue. For example a script could take a parameter specifying a file to add to the current open project in Xcode. Another script could take a parameter to remove a file from the current project. Then your other IDE could just call these scripts like any other command line tool in your build script.
I'm not aware of any built-in functionality to accomplish this. If you need it to be automatic, your best option may be to write a Folder Action AppleScript and attach it to your project folder.
In all likelihood it would be a rather difficult (and probably fairly brittle) solution, though.
It's not pretty, and I think it only solves half your problem but... If you recursively copy, then quit xcode. Then you delete the folders, and replace them with simlinks to the original folders, you at least have files that are seen as code, and they are in the same files as the other IDE is looking at... You still will need to manually add and remove files.
I sort of doubt that there's a better way to do this without some form of scripting (like folder actions) because xcode allows you to have multiple targets in one project, so it's not going to know that you want to automatically include all of the files in any particular target. So, you're going to have to manually add each file to the current target each time anyway...
One way to import another file from add/existing file:
and set your customization for new file that added .
see this
Related
I have a solution where there is a dependency on 7zip's sfx. Out of desire to keep the entire solution (plus the sfx) managed and coordinated, I want to create a new project to house all the source files that is used by sfx, and when building, execute a command line that tells 7zip to build a sfx from the source files, and place into the output so that it can be then referenced by actual Visual Studio projects within the same solution.
I think I can figure the command line by using Build events and providing the appropriate macros to ensure that the 7zip's output is placed into the target folder with appropriate name so that it can be then correctly referenced by other VS projects. But what I am not sure about is what Visual Studio project I need to use or steps to take to tell Visual Studio that there isn't going to be any code to be compiled in this project and it just has to execute this script I give it.
The closest thing I can come up with is VS's Make project but I don't know if that is the right thing since this has nothing to do with Make at all.
So, what is the Visual Studio project template I need to use? If empty, then what configuration do I need to perform so that it won't try and look for some code files to compile but instead just execute scripts as part of the solution's build?
For now, it seems that using C++ Makefile Project works. I had to make few configurations:
1) I had to specify the project's "Configuration Type" as "Utility"
2) I used Pre-Build event and provided a command to invoke a batch file included in the project. The batch file then takes care of everything.
3) Normally, non C++ files are not considered for determining whether build is needed or if it's already up to date. To ensure that a new build is perform if the batch file or other key files are edited, I set the file's "File Type" to "MakeFile". Even though it isn't actually a Make file, it ensures that any edits made to the file will cause a new build.
The downsides I've found so far are:
1) C++ uses "Filters", not folders. Therefore, keeping the files in same directory structure is a big PITA. One can "include" files and get a one-to-one mapping between "Filters" and the actual directory structure on disk but it's annoying and tedious. Wish it was a C# project
2) I'm a bit wary about how it will detect new files or other changes for files that I didn't explicitly set to "MakeFile". I expect the source to be stable but I worry that when I realize I need a new file and add it, I might forget and not notice that the build is not correctly including the new file.
I'm not sure if this is the best method but this works for my purpose - having a project to manage external tools as part of bigger build process.
Codeblocks cannot find definitions or declarations of some functions in my project.
Question: Is there a way to force a re-scan of the source tree?
I believe that all of the relevant files are included into the project.
(Just checked: it cannot find by name a struct declared in an opened file.)
First, let me give a couple of ways to help C::B find your declarations/definitions.
Although somewhat obvious, you should make sure the function is in a file that is either:
1) part of the project itself (i.e. it should be shown in the projects->workspace window). If you intended it to be part of the project but it isn't there, then go to project->add files and add the file.
2) If you don't want/need the file to be part of the project but you still want to access the declarations/definitions, you need to let the project manager know where to find the file. You can do this in project->build options and set the search directories. Be careful when setting the search directories...you can set it for the whole project or build target (debug or executable).
Note: one common problem occurs when you have multiple projects open in C::B. Even though all your projects are "open", there is only one that is "activated". So, just because you have a file open, it doesn't mean the file is part of the activated project. You can do search-->open files" which will find code in a file if it's open but not in the current active project.
The only way to "re-scan", is to rebuild your project after making changes in the source code or project settings. You may have to restart C::B. If you still can't find the declaration/definition after doing the above, I would suggest you make a sample program and see if it will find the declaration/definition. If it does, then you can check the settings between your project and the sample project. In the worst case, you can copy your code from your project to the sample project. If that doesn't work, you can reinstall C::B and try again. Not fun but sometimes it works.
You can try, rebuilding the project, but make sure at least one other file includes the header for the structure or make sure the header and source file are included in the project.
I have a directory of source files (.h and .m) that are shared between multiple projects. I'm not building them as a static library; instead, I just include the source in each project.
Previously, I was copying the source into each project independently, but now, I'd like to move to having a single directory that has all of those shared files it, and include a folder reference to them in each XCode project that uses them.
Including them as a folder reference (blue folder) is no problem, and I can add the path to the header includes so that the files in the project can see them. But they're not being built, and thus I'm getting link errors.
How do I get Xcode to build the source in the external directory?
folder references don't work like that in xcode.
this is exactly what an external target (e.g. static library) is for... seems strange that you would choose to duplicate (a portion of) the maintenance for every project. with a library, you can also reduce the build and indexing times (assuming the build settings match some of the time).
if you insist that a static library is a bad idea... you can approximate what you want by creating a custom build script phase for your target (you will need to configure a script, rather than passing the xcode folder reference as input).
I know this might sound a bit strange but I'd need to generate a xcodeproj automatically.
Basically scanning the filesystem and adding certain files to the project and to a specific target.
The main reason behind this, is that I work in an zero IDE environment. Thus, we have our own build system and source files are added and removed all the time.
I could use "create folder references for any added folders". However, xcode won't ever parse source files if they aren't part of any target. So, no symbols, no code completion...
To me, my only option would be to "auto-update" my xcodeproj with a script...
Thanks in advance for your inputs!
Cmake is one option (see this related question) and there's also Scons which I think can generate Xcode projects. There's also Qt's qmake which can generate the project files, but this is probably overkill unless you're using full Qt.
You can either user AppleScript (or anything OSA-compatible) to automate the process of creating the project in Xcode itself, or you could look at CMake, which is able to generate Xcode project files.
I would like to harvest a folder with a lot of files by using heat.exe. But instead of harvesting all files, I would like to exclude specific file extensions like "*.txt" or something like that.
How can I do this?
I think the only option for now is to harvest the entire folder and apply a transform to the resulting .wxs file (see -t:<xsl> switch) to exclude what is not required (txt files in your case). However, I didn't try the 3.5 version of heat (judging based on the 3.0), but I don't think there are changes in this area.
I'm not a huge proponent of this pattern. How do you ensure change control when using a non-deterministic process? How do you know a file that appeared in a directory really should ship in a product and how do you know a file that vanished from the directory shouldn't break a build? How do you know you are breaking the component rules and creating servicability issues?
I used to do dynamic file linking in the 1990's because it was "easy" but I can remember it biting me many times and I haven't done it ever since.
I know Bob Arnson used to agree with this view point:
http://www.mail-archive.com/wix-users#lists.sourceforge.net/msg03420.html
But now in WiX 3.5 I'm starting to see capabilities that support dynamic linking and I just don't understand why they would go that way. I'd much rather update a WXS file and check it back into source control then risk putting my deployment process on autopilot.
Instead of trying to figure out how to harvest selected files from of a folder, I use a before build action to populate a folder with just the files that I want harvested. The following workflow has been working for me:
Delete a "files" if it exists
Create a "files" folder
Copy the files to the "files" folder. I use the robocopy build action, that gives me enough control to specify which files to include or exclude.
Harvest the entire folder.
I have it set to run the harvest action conditionally, just for debug builds. Release builds are generated from our TFS server and use the generated .wxs from source control. It should be OK to run harvest on the build server, but it's an extra step and not having it run eliminates the "non-deterministic process" problem described by Christopher Painter. Other than that one step, the same steps execute on the build server as they do on my dev machine.