Many software engineering tasks lead to a point where one needs to compare the command line
flags between two invocations of the same tool (for example, gcc).
For example, consider that a build engineer is migrating from one build tool to another
(for example, from make to ninja).
At some point, with verbose output turned on, one might see a compile command that looks
like:
/Library/Developer/CommandLineTools/usr/bin/clang -DBUILDING_LIBCURL -DCURL_STATICLIB -DHAVE_CONFIG_H -I/Users/yourusername/src/CMake/Utilities -I/Users/yourusername/src/CMake/Utilities/cmcurl/include/curl -I/Users/yourusername/src/CMake/Utilities/cmcurl/include -I/Users/yourusername/src/CMake/Utilities/cmcurl/lib/../include -I/Users/yourusername/src/CMake/Utilities/cmcurl/lib/.. -I/Users/yourusername/src/CMake/Utilities/cmcurl/lib -w -std=gnu11 -o CMakeFiles/cmcurl.dir/escape.c.o -c /Users/yourusername/src/CMake/Utilities/cmcurl/lib/escape.c
Now you're done porting your build to another tool, e.g. ninja, but you're not
getting the same output, something is off. You dig down, and discover compiles that look like:
/Library/Developer/CommandLineTools/usr/bin/clang -DBUILDING_LIBCURL -DCURL_SHAREDLIB -DHAVE_CONFIG_H -I/Users/yourusername/src/CMake/Utilities -I/Users/yourusername/src/CMake/Utilities/cmcurl/include/curl -I/Users/yourusername/src/CMake/Utilities/cmcurl/include -I/Users/yourusername/src/CMake/Utilities/cmcurl/lib/../include -I/Users/yourusername/src/CMake/Utilities/cmcurl/lib/.. -I/Users/yourusername/src/CMake/Utilities/cmcurl/lib -w -std=gnu14 -o CMakeFiles/cmcurl.dir/escape.c.o -c /Users/yourusername/src/CMake/Utilities/cmcurl/lib/escape.c
Is this the same as the above? Is it different in meaningful ways? What changed, and does it affect the build? You could stare at the command line flags and try to compare them with previous ones, but that quickly turns your brain into mush. You could also put together some bash-fu to compare them, but that's a bit of effort to get right, and you won't get handy links to docs. That's why this site exists. See the answer!
This tool is for build engineers or people working on software build systems (or, I suppose, anyone that has a need to compare large sets of command line flags). This tool covers a distinct but important problem when comparing two sets of command line flags for differences.
While it is possible to plop together a few sed one-liners to compare command
line flags, it's hard to get the details and edge cases right. In addition, you don't get a
nice visual diff and links to documentation.
Just follow this link and paste your two sets of command line arguments into the fields.
No. Command line comparison happens entirely in your browser. The only
thing that the server knows about is which tool your command line(s) use (e.g.,
clang, gcc, etc). The first word of your command line is
used to detect the tool. The rest of the command line is completely ignored, and lives in
your browser only, so you don't have to worry about leaking non-public path details that
include secret product code names, etc.
It does this so that it can fetch a database of common flag definitions and provide links to their documentation pages.
The way this works is the following:
/usr/local/bin/gcc -o foo foo.cc ..., this would be
/usr/local/bin/gcc.
gcc).
gcc-flag-defs.json), and compare each of the command line
flags given and annotate with links to documentation.
Currently, the definitions of command line flags for the following tools exist in the tool database:
gcc/g++ [ 8.3, 9.2 ]
clang [ 10 ]
ld.lld [ 10.1 ]
Not at this time (see the points above). Since this site does not track your entire command line(s), there's nothing to share.
This functionality might be possible via obfuscated URL fragments or something, but it does not exist at this time. Your command line comparisons live only in your browser.
Yes. You just won't get handly links to the flag definitions. The comparison will still work though.