I have a simple script that runs xcodebuild for a C++ project. However it prints out a huge amount of output for each file compiled, 10-20 lines, which makes it impossible to read easily. Ideally I'd jut like to see a list of the files compiled, one per line.
I'm not a nix guy but it seems like nix command-line can do pretty much anything... is there a neat way to do this? xcodebuild itself doesn't seem to have any control options for verbosity.
This question might help:
How to filter the xcodebuild command line output?
Basically, you can just pipe the output and search what you need to show with grep.
Related
gcc has so many warning options, and I want to turn a bunch of them off (I'm compiling a ton of old code that's known to work, but generates lots of warnings). I suppose I could turn off all warnings, but surely that's not advisable, but I also don't want to set my CFLAGS to contain 10's of -Wno_... flags that will appear on the screen as each module compiles.
What would be ideal would be to be able to put a bunch of these flags into a text file and reference that on the command line. Maybe that's possible, but I can't find an option for that in the manual pages. Anybody know if such an option exists?
Files containing commandline options to be used in the way you envisage
are often called response files.
GCC compilers support response files, which may contain any or
all of the commandline arguments (not just -opt options). The usage is:
gcc [args...] #file [more args...]
where file is a file of space-separated commandline arguments.
#file is documented in the GCC manual in 3.2 Options Controlling the Kind of Output
If you like response files for your personal builds, feel free.
But in professional build practice they are not popular. Consider that Exhibit A for
the the diagnosis of a build break or problematic build is the complete build
log, in which we hope to find the complete sequence of commands with
all of their arguments. #file frustrates that hope, and holds us up while we look for
file or ask somebody remote to send it to us, or post its contents (perhaps on Stackoverflow!)
When we see it, it can be difficult or impossible to eliminate the eventuality that what we are seeing is
not actually what was in file when the build was run. Build logs filled with
multi-kilobyte command lines are normal and are everyday reading for build engineers.
(make noob here)
I did the following:
Configured a C++ project with CMake.
In one terminal tab, ran make to start building the whole project.
Got bored of waiting for the whole thing to build, figured I could
just make the subfolder I'm working on at the moment.
Without stopping the ongoing build in the first tab, opened a second tab and ran make from said subfolder.
Things looked pretty normal for a short while, then suddenly second tab started displaying build outputs related to the whole project, not only to the subfolder. I figured what I tried didn't work as I expected, so I CTRL-C'd the second tab.
That's when the weirdest happened: in the first tab the build output was mixed with lines coming form the specific folder I wanted to build. And the build went way past 100%, up to 128%!
My question is: what exactly does 'make' do when launched more than once at the same time?
Am I correct to think that the multiple make commands where somehow "merged" in the same process??
This is more a question about the makefiles that CMake creates and how they work. It's these makefiles which do things like track the percent complete, etc., not make itself. It's quite possible that by starting a second build in the same directory, you've messed up whatever facilities the CMake makefiles use to track progress.
The short answer is that no, it's not possible that one invocation of make will somehow "take over" or merge another invocation of make. As far as the make program is concerned they know nothing about each other. However since both are operating on the same filesystem, if one make writes files in a way that can confuse another make, you could see strange behaviors.
The cmake-generated makefiles are very complex; I've never actually tried to understand completely how they work. I've always thought it a shame that no one has tried to implement a CMake GNU Makefile generator in addition to the Unix Makefiles generator, that took full advantage of GNU make features. I'm sure the results would be easier to read and probably faster. But it seems unlikely this will ever happen; CMake users who care more about speed than portability are probably just switching to use Ninja as a generator.
I am trying to compile a bash project into a distributable binary. I tried shc, and it worked, except all my source statements were broken. I have numerous source statements to keep the code base cleaner, but they are broken when compiled with shc. How can I compile down my bash project so that instead of having a bunch of .sh files, the end user can just have one single file?
Shc is an obfuscator, not a compiler. At the end of the day, it still invokes /bin/sh or whatever, and feeds it your original script. It has not a slightest idea what your script actually does. If it needs an additional file to source, you have to supply it at an appropriate location.
You may want to investigate things like SHAR. Build anarchive, then compile it with shc if you want.
It sounds like all you're missing is a facility to expand all your source statements. That should be fairly easy to write if your codebase is fairly consistent in its use of those statements: just write a script to expand them inline and away you go.
Alternatively, just put all your scripts into a single Zip file or tarball and tell the user to extract the contents of that one file, or if even that is too much I'm sure you can imagine a way to encode the zipped contents of all the non-main files into a giant comment at the bottom of the main file, and have it extract what it needs before proceeding.
Or, you know, use the appropriate installer for your system. Build an RPM for RHEL or a Debian package or a Windows MSI or whatever....
I have a huge file with all the commands I use on and off the commandline. This file is getting harder to open and navigate as its size gets larger. I am looking for a commandline utility that makes this process easier. I found this gem, which does something similar to what I want, but it's terrible with long lines of code with multiple quotation marks.
What does everyone use to keep your code snippets and easily access it from your terminal?
I keep a similar file myself. This example isn't directly useful with your file. However when I find that I need to run a particular command I recently used, without looking it up again, I run a grep on history.
For example:
history | grep "svn co"
You may try Komandi, a multiplatform command snippets manager.
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.