-
Notifications
You must be signed in to change notification settings - Fork 443
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build env setup scripts + initial skeleton of cross-plat scripts for clang-format #11
Conversation
tools/setup-buildtools.sh
Outdated
apt-get install -qq automake | ||
apt-get install -qq libtool-bin | ||
apt-get install -qq cmake | ||
apt-get install -qq sqlite |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need SQLite?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not at this point.. I'll comment that. We might still need some abstraction layer for the storage. sqlite being a pure C lib has the property of universally available across all OS (windows-10+/downlevel, win10-uwp, Mac, iOS, iPad OS, Linux, Android, Chromium/Chrome OS, etc.).
.clang-format.chromium
Outdated
BraceWrapping: | ||
# TODO(lujc) wait for clang-format-9 support in Chromium tools | ||
# AfterCaseLabel: true | ||
AfterClass: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AfterClass: true | |
AfterClass: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one was a verbatim copy of the file from Chromium tree.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I kept it as-is in Chromium mainline, renamed this to .clang-format
.gitattributes
Outdated
*.props -text diff -merge | ||
*.pbxproj -text diff -merge | ||
|
||
## Resource files and UI design descriptions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussed during the SIG meeting, let's start with a minimum set
*.bash text eol=lf | ||
|
||
## Windows batch and PowerShell scripts | ||
*.bat text eol=crlf |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Per the meeting and Reiley's comment, I think we should start from an empty file and add things as we find we need them. The EOL stuff looks very useful, but I think git already does a good job of guessing e.g. text vs binary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed to reduce the scope of it. Unfortunately GitHub doesn't always guess it properly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reduced the .gitattributes to very small set, pretty much core essential set.
It's still there for enforcing different lf vs crlf settings for different file types.
.gitattributes
Outdated
##### Source code ##### | ||
|
||
## C++ and C source files | ||
*.c text diff=cpp |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does diff=cpp do? e.g. Which tools benefit from this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
diff=cpp allows GitHub to visualize a diff in a 'smarter' way - using language-specific diff parser. From gitattributes man: https://git-scm.com/docs/gitattributes
- cpp suitable for source code in the C and C++ languages.
i.e. git diff --word-diff is easier to read with that attribute. There are several projects doing it that way. I'm not sure if it's still relevant as of 2019? But this is one example with some logical reasoning behind this practice: http://lkml.iu.edu/hypermail/linux/kernel/1108.3/01118.html
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's cool! Is there a before/after example? I'd be surprised if GitHub has special handling for diff=cpp
but doesn't know to apply it by default to *.cc files (considering they e.g. guess the breakdown of languages for every repo)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Basically git itself in its own .gitattributes file prefers to explicitly specify the proper diff viewer for .c and .h files... I think we might want to keep that similar logic in our repo. Reference:
https://github.com/git/git/blob/master/.gitattributes
Maybe adding whitespace=space is also something we may want to consider, e.g.
*.[ch] whitespace=indent,trail,space diff=cpp
to enforce spaces instead of tabs.
.gitignore
Outdated
*.lo | ||
*.o | ||
*.obj | ||
# User-specific files |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this file should also start from empty (not even the github default) and we should add things as we find we need them.
I don't think that "it's safe to git add everything" should be a goal. Rather, we should gitignore stuff if we find it's annoying for a large set of users, e.g. if msbuild generates lots of files in the source dirs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reduced it going with .gitignore default from here:
https://github.com/github/gitignore/blob/master/C%2B%2B.gitignore
@@ -0,0 +1,65 @@ | |||
#!/bin/sh |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This script does a lot. I would prefer a README, rather than running this on my workstation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll make it optional. It bootstraps a lot of common C++ goodies, so it's easier to write a docker file using that script.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...although I think for Linux containers - it'd be better to install a lot of these as a docker build image dependencies, so that the build script doesn't have to install again. Perhaps we should have a separate commit with docker configs for Windows and several common Linux distros. These scripts are useful for folks not using docker, i.e. you can schedule these to run in a GitHub action without needing an extra docker image build.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that automating (and thereby documenting) build deps would be very useful wrt Docker.
I'm happy to keep this script here, I'm just wary of running things myself (especially under sudo) ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was essentially the minimum set of libs + tools required to compile our own telemetry SDK stack, to bootstrap on any default image, such as Raspberry Pi / Raspbian, or an older Ubuntu 14.xx, 16.xx, RedHat, etc.. It did accumulate some meat over time. But in essence it's something that can be just scheduled to run inside of a GitHub Action on machine which by default may not have all the needed deps. It doesn't require docker. It runs once and creates .buildtools file, indicating that the build tools have been deployed, so it won't rerun again for incremental builds.
Alternate solution is to create a separate set of docker image configs (quite a bit of duplication). Then assuming that each image is cooked properly with the right set of tools- it'd be then as easy as invoking cmake in that image, not needing the setup of all build tools.
Most big projects in some way would still enforce their own tooling, their own compiler, etc. like chromium/tools/depot_tools and would still be much more bulky than this shell script. I can truncate that to one command running apt-get install -qq all_deps_at_once + share some docker configs for an equivalent set of tools.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm happy to keep the script. Let's see what others think.
git fetch origin pull/11/head:pr11
git checkout pr11
cat /path/to/some/file.cc | clang-format-8 -style=file
mv .clang-format.chromium .clang-format
cat /path/to/some/file.cc | clang-format-8 -style=file My preferences:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still think this does more than we currently need, but I'd prefer to keep things moving forward. :)
IndentWidth: 2 | ||
|
||
# Keep lines under 100 columns long. | ||
ColumnLimit: 100 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer 80.
# Always break before braces | ||
BreakBeforeBraces: Custom | ||
BraceWrapping: | ||
# TODO(lujc) wait for clang-format-9 support in Chromium tools |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably don't want username here.
# Use 2 space negative offset for access modifiers | ||
AccessModifierOffset: -2 | ||
|
||
# TODO(jmadill): Decide if we want this on. Doesn't have an "all or none" mode. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ditto.
## Python scripts | ||
*.py text eol=lf diff=python | ||
|
||
## Perl scripts/libraries/modules |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we're going to use any perl.
@@ -1,3 +1,4 @@ | |||
# Ref. https://github.com/github/gitignore/blob/master/C%2B%2B.gitignore | |||
# Prerequisites | |||
*.d |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Both CMake and bazel do out-of(-source)-tree builds. We don't need to ignore deps or objs here.
However has the magic powers to merge, please help to merge this - I can work on incremental updates to address some nit-/minor suggestions in a follow-up PR. |
Merged |
Reapply "Change OTLP HTTP content_type default to binary (open-telemetry#2558)" (open-telemetry#2…
This is a humble attempt to setup some skeleton of a build environment for Windows, Linux and Mac.
Proposed layout:
Usage instructions for Windows cmd.exe shell:
Usage instructions for Linux and Mac Bourne shell:
In both cases either sudo or elevation is required to install the tools on machine. Unix shell script is trying to cover RedHat, Debian-based distros and Mac, with an assumption that cmake, gcc and/or clang, alongside with clang-format tooling are the common core required dependencies. We can discuss what specific compiler version(s) we require or support in a subsequent commit..
But the first actual functional piece of that setup is a proposal to converge on clang-format and a corresponding .clang-format style in a platform-agnostic way.
Code formatter instructions provided in docs/using-clang-format.md , covering some common "zero installation" options that can be used from various common IDEs, i.e. not requiring the command line tooling.
My personal preference is a custom modified LLVM-based in .clang-format . Please take a look at the output of that. Since we all have different backgrounds - alternatively I am open to adopt the .clang-format.chromium - Chromium style. If we agree on Chromium style, then we'd integrate the one that is .clang-format.chromium , naming that one the .clang-format file in the top folder of the source tree.