I'm having trouble with Xcode 4.5.2's analyzer. It is able to find issues:
But, while the issues are displayed on the top bar:
,
the issues are not shown inside the file editor. Without this information, there is no practical way to know what the analyzer was talking about.
Is there a log file somewhere where I could find a line number for the detected issues? Any other workaround or setting tweak?
The only workaround I can think of is running the analyser from the command line. That can be done directly on Xcode projects (ie, no makefile barbarism required) and should give you direct textual feedback.
Related
I am writing an app using applescriptobjc in xcode, and while making the archive I see the source code is still inside the package, is there a way to hide it or transform it completely to binary code?
Thanks
I may be a year late to the discussion but I asked the same question around the same time as you did last year and hope that the answer I got will satisfy your own question. Here is an extract answer from
my own question:
When you save the AppleScript file you have the option of checking "Run Only" - in that case the script is compiled into a new form that can be run exactly as the original script, but it is not meant for further editing/development.
It doesn't mean that the run-only file is complete protected or non-readable, but parts of your code, comments, etc. are not included or not easily readable.
If you want to do more you'll need a code obfuscator if you still want to use AppleScript - however I'm not sure if one exists on the market, or you need to develop your own.
As you can see, a simple way to do this is:
Open your final AppDelegate.applescript file in Script Editor on the mac.
Select: File > Export...
2.1. Don't change the file name but override the archive file
2.2. BEFORE SAVING: Choose Run-only checkbox from the save options but leave the File Format as Script
Now your file cannot be opened in plain text as it is set to Run-only. Please remember that it is not a 100% read-proof solution, but works great for small projects (provided you are not rushing the final export and don't forget to perform the above mentioned steps before handing it over to the customer).
I hope you can make the most of this answer and still deem it useful. Let me know how you get on or whether you have any more questions. Perhaps you have since found a far better solution (or just an alternative), if so, I am still looking for the next best thing in source code protection.
In Xcode 9.2. (and maybe earlier versions) you can find under Build Settings the item OSACompile and can choose to compile to an executable only directly from Xcode.
I've set up an Xcode project where part of the code (a folder in this case) comes from a svn repository.
The folder is constantly updated by an external partner and it contains .h and .m files. In particular, these files are included in the project since set up as Header Search Paths and Library Search Paths within my Target.
Since, .h files contain a lot of warnings (I receive the Showing first 200 warning only message), Xcode does not allow me to show my code warnings.
Based on this scenario, how is it possible to prevent Xcode to show those warnings for that specific folder?
I followed few discussions within SO (Selectively disable GCC warnings for only part of a translation unit?, Turn off warnings coming from subprojects) but I haven't found a solution yet.
Thank you in advance.
Since I've found a solution I reply to my own question. Hope this can help other people.
A partial solution for the problem can be found here at How to disable new Xcode 4.6 warning for whole project ? “… used as the name of the previous parameter rather than as part of the selector". I upvoted!
Obviously, I'm waiting the vendor will fix the problem since this workaround disable such type of warnings for my own code. And I don't want such type of behavior.
Cheers.
I am looking at a project which contains a mix of source files - built on a variety of systems. When I attempt to compile it, I'm getting some errors from the pre-processor which suggest that my line ending formatting mix is just not cutting it.
Is there a quick way to correct this in Xcode? I'm looking to globally change the line ending format in all of my files, save, and recompile.
I don't know of an xcode way of doing it but you could fix it with sed.
ls *.c | sed 's/.$//';
You probably need to do this on an entire project, an utility like flip might work out better. You can get the source from the website.
I would like to change the output file name based on certain criteria that I'm checking with #defines. A little background, I'm doing this because I've decided to use VS2010 in one of my projects to regain intellisense. However, this is causing some other problems with Google Test, and the rest of my team is on VS2008. So, I would like to build a GTEST_VS2010.lib if I'm on VS2010, and GTEST.lib otherwise. I was hoping I could trick the compiler with #pragma comment(linker...
but that doesn't seem to be allowed by MS. Thanks for any help.
VS2010 converts project and solution files, doesn't it? Then you don't have a problem since you can't use the project file with VS2008 anyway. Just change the linker's Output File setting.
Otherwise, you probably should just consider adding another configuration to your solution.
I'm working on a project which makes substantial use of code generation. Some of the files it generates contain >0.25 million lines of code. VS (2K5) doesn't cope too badly, but R# (4.01) throws an out of memory exception every two minutes or so.
Splitting them out into partial classes/separate files isn't an option in the immediate term, though it may be later.
Are there any clever IDE tricks to dealing with this?
EDIT: so people are immediately saying (very sensibly) 'don't have a file that big' and suggesting ways to break it out into smaller files.
That's fine, but I'm on a time-boxed task taking a look around and deciding what to optimise. My problem is very specifically 'how to view an insanely big file in an IDE without pain', not 'how to refactor the project'. For purposes of the question please imagine the file is read-only. :)
I would at least change huge files extention to something like .cpp_gen or .cpp_huge to remove syntax highlighting, outlining etc. and then reassign build tool back to C/C++ compiler tool for them.
Seems like this R# tool (is that Resharper?) is the problem. Can you disable it?
Otherwise, changing the file type for the generated code might make sense - presumably, you aren't going to be doing major editing on those files, so losing syntax coloring and other features specific to source files wouldn't be an issue.
WOW!
250 000 lines of code?
you should think not in a machine point of view, but in a human been point of view. Let's say that you want to pass that code to someone else, can you see the time to see what the code does?
Design Patterns were made to deal with this ind stuff, try to start small, refactoring it, then go deeper and start applying more D.P.
you will have less and less lines of code, and Yes, one of the best tricks is to separate into several files according to it's propose.
Assuming you're not hand-editing your generated code. (=BAD IDEA!!)
You could put the generated files in a separate solution that you compile from the command line and then reference those dll's from the project you're working in.
Is the problem when you open the file for editing in Visual Studio? I've noticed that VS editor can be quite slow and inefficient on large files. Also, you could try turning off certain options, e.g. word-wrapping kills my machine for some reason.
Otherwise you could use something else like Textpad with syntax highlighting installed to edit the problematic large source file... not as nice, for sure.
Don't use visual studio. There is too much going on in VS.
Since the file is read only, you wont be using any IDE features (Intellisense, Refactoring tools, formatting).
You will probably get better performance using a simpler application, such as notepad++ for simply viewing the file. Notepad++ will do standard language highlighting if you like color.
Can't you break up the files and use the preprocessor to bring them back together when you compile?
It must be possible somehow to group large chunks of those files in separate libraries. You'd then separate them into several projects. Tried this? What the is the current structure of your source code/ project?