Makefile - Make it a bit more usable #701
Conversation
| leo-* | ||
|
|
||
| # JetBrains IDEs | ||
| .idea/* |
There was a problem hiding this comment.
Really dislike adding personal things to .gitignore. People's personal setups should use .git/info/exclude instead
There was a problem hiding this comment.
I disagree here I'm afraid 🙏 😄 - it's an assumption that is very problematic. I also suggest to add common IDE .gitignores to any other repo if missing actually, there aren't many common IDE stuff to ignore to cover 95% of cases (super niche editors and custom metadata set-ups aren't relevant).
I think this an opinion vs pragmatism scenario;
Even if it would've been nice to have people systematically use personal configs in theory (good mechanism, that's what its for, might be nice to separate setup-based-ignores and project-based-ignores), in practice, most developers just don't bother with this.
It's enough that those exist in non-negligable numbers to justify removing this as a barrier imo.
Especially a must for open source repos IMO - We can't assume those things on external contributors even if we wanted to assume+enforce using personal git profiles inside a company.
For those who do use personal gitignores - this is harmless, for those who don't - omitting this for cleanliness/aesthetics reason will add needless friction which is real.
To illustrate/support:
- internal example - dvc's .gitignore
- external example for something that I know most people in iterative like - fastapi's .gitignore
There was a problem hiding this comment.
Another reason just occurred to me (re: cloud IDE) - the case for ephemeral dev boxes which may not be pre-configured in this way
There was a problem hiding this comment.
I think ide-specific exclude paths are perfectly fine in .gitignore. It's a low impact change that we're spending an unreasonable amount of time discussing.
@0x2b3bfa0 So - just personal preference / practice. If you (or anyone) find this detrimental I'll just remove 😄 |
This is too subjective to unbury my “detrimental sledgehammer” but I can't imagine any plausible case where cross-compiling this project during local development would become a commonplace practice. 🤷🏼♂️ |
omesser
force-pushed
the
make_make_useful
branch
from
be8945b to
8359757
Compare
| GOARCH=${shell go env GOARCH} | ||
| TF_PLUGIN_INSTALL_PATH=~/.terraform.d/plugins/${HOSTNAME}/${NAMESPACE}/${NAME}/${VERSION}/${GOOS}_${GOARCH} | ||
| TPI_PATH ?= $(shell pwd) | ||
| LEO_PATH ?= $(shell pwd)/cmd/leo |
There was a problem hiding this comment.
If we're only using these paths to specify the build entry point, they can be relative to the Makefile. Actually, since we're only using them in one single location, there's not much point in defining constants for them
| leo-* | ||
|
|
||
| # JetBrains IDEs | ||
| .idea/* |
There was a problem hiding this comment.
I think ide-specific exclude paths are perfectly fine in .gitignore. It's a low impact change that we're spending an unreasonable amount of time discussing.
leoandterraform-provider-iterativebinaries in repo rootbuildtarget now uses the above instead of the current "check-build" (checks validity, but produces no binaries, which might be useful)install_tpitarget - built and installedleobin into tf plugins (probably unwanted behavior) - fixedmake targetswhich acts as--help)