Skip to content
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

Merged
merged 5 commits into from
Dec 16, 2019

Conversation

maxgolov
Copy link
Contributor

@maxgolov maxgolov commented Nov 4, 2019

This is a humble attempt to setup some skeleton of a build environment for Windows, Linux and Mac.

Proposed layout:

  • tools - contains various scripts for setting up the basic build tools

Usage instructions for Windows cmd.exe shell:

call tools\setup-devenv.cmd

Usage instructions for Linux and Mac Bourne shell:

. tools/setup-devenv.sh

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.

apt-get install -qq automake
apt-get install -qq libtool-bin
apt-get install -qq cmake
apt-get install -qq sqlite
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need SQLite?

Copy link
Contributor Author

@maxgolov maxgolov Nov 4, 2019

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.).

@maxgolov maxgolov changed the title Build env setup scripts + initial skeleton of cross-plat scripts for clang-format [WIP] Build env setup scripts + initial skeleton of cross-plat scripts for clang-format Nov 4, 2019
BraceWrapping:
# TODO(lujc) wait for clang-format-9 support in Chromium tools
# AfterCaseLabel: true
AfterClass: true
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
AfterClass: true
AfterClass: true

Copy link
Contributor Author

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.

Copy link
Contributor Author

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

.clang-format.chromium Outdated Show resolved Hide resolved
.gitattributes Outdated
*.props -text diff -merge
*.pbxproj -text diff -merge

## Resource files and UI design descriptions
Copy link
Member

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
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

@maxgolov maxgolov Dec 2, 2019

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
Copy link
Contributor

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?

Copy link
Contributor Author

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

Copy link
Contributor

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)

Copy link
Contributor Author

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
Copy link
Contributor

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.

Copy link
Contributor Author

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
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

@maxgolov maxgolov Nov 5, 2019

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.

Copy link
Contributor

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) ;)

Copy link

@top-5 top-5 Nov 5, 2019

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.

Copy link
Contributor

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.

@g-easy
Copy link
Contributor

g-easy commented Nov 5, 2019

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:

  1. -style=Google
  2. .clang-format.chromium
  3. .clang-format

Copy link
Contributor

@g-easy g-easy left a 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
Copy link
Contributor

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
Copy link
Contributor

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.
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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.

@maxgolov
Copy link
Contributor Author

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.

@rnburn rnburn changed the title [WIP] Build env setup scripts + initial skeleton of cross-plat scripts for clang-format Build env setup scripts + initial skeleton of cross-plat scripts for clang-format Dec 16, 2019
@rnburn rnburn merged commit 34988af into master Dec 16, 2019
@rnburn
Copy link
Contributor

rnburn commented Dec 16, 2019

Merged

@reyang reyang deleted the maxgolov/clang-format branch July 21, 2020 19:00
GerHobbelt pushed a commit to GerHobbelt/opentelemetry-cpp that referenced this pull request Jun 21, 2024
Reapply "Change OTLP HTTP content_type default to binary (open-telemetry#2558)" (open-telemetry#2
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants