While many entries are now 4 or 5 years old, I always greatly appreciated How I Start for this kind of thing, and wished documentation like it got more popular. I recently had a bit of a primal scream trying to get an OCaml setup and I identified what I’d love most in any programming environment for a project, especially when jumping into a new language:
Project/directory structure.
make-like invocations to do the following:
Build artifact
Run
Run tests
Clean
Perform static analysis, if there are external tools (e.g. mypy, formatters)
Deploy
Open an interactive shell with definitions loaded.
Easy to add reproducible dependencies (usually pinned with a lockfile these days).
Use a language server (or plugin, or IDE) to give features like:
Type of highlighted expression
Jump to definition
Find usages of highlighted term. Safe rename/delete.
And there’s only one or two languages I can do all of 👆 with, and it often takes a lot of tweaking. Also, many of the commands get slow as teams grow, so it’s less about quick iterative cycles (thinking of every slow pytest suite I’ve ever sat through for a ~50kloc project…).
Did I miss any? And how do we proliferate the knowledge or solidify the tools so that fewer of us have to work around the lack of these things?
I think a lot about Bret Victor’s mentioning sometime that a lot of programming skill is about being able to “play computer” in your mind, modeling its limitations while you work. But we do this… in front… of a computer! 😛
Anyways, happy to see this sentiment (“it’s more than just the source code”) getting traction 🙂
I am a big fan of cookiecutter for much of this. It’s like an executable version of some of those “how I start” essays, but it doesn’t quite take you from absolute zero the way some of those do.
For stuff that’s new to me, I like to start by finding an opinionated cookiecutter for it. Once I’ve been at something long enough to have formed a more concrete opinion of my own, I’ll often fork one to suit my environment or needs a little better.
It’s not a full answer to your question, but it gets me going with a lot less tweaking than I used to do.
At $work, we used autohell for a few months. I ended up hand-rolling a configure script that suits modern *nix quite nicely. I now use it as a base for personal projects.
While many entries are now 4 or 5 years old, I always greatly appreciated How I Start for this kind of thing, and wished documentation like it got more popular. I recently had a bit of a primal scream trying to get an OCaml setup and I identified what I’d love most in any programming environment for a project, especially when jumping into a new language:
make-like invocations to do the following:mypy, formatters)And there’s only one or two languages I can do all of 👆 with, and it often takes a lot of tweaking. Also, many of the commands get slow as teams grow, so it’s less about quick iterative cycles (thinking of every slow
pytestsuite I’ve ever sat through for a ~50kloc project…).Did I miss any? And how do we proliferate the knowledge or solidify the tools so that fewer of us have to work around the lack of these things?
I think a lot about Bret Victor’s mentioning sometime that a lot of programming skill is about being able to “play computer” in your mind, modeling its limitations while you work. But we do this… in front… of a computer! 😛
Anyways, happy to see this sentiment (“it’s more than just the source code”) getting traction 🙂
I am a big fan of cookiecutter for much of this. It’s like an executable version of some of those “how I start” essays, but it doesn’t quite take you from absolute zero the way some of those do.
For stuff that’s new to me, I like to start by finding an opinionated cookiecutter for it. Once I’ve been at something long enough to have formed a more concrete opinion of my own, I’ll often fork one to suit my environment or needs a little better.
It’s not a full answer to your question, but it gets me going with a lot less tweaking than I used to do.
That looks really cool! I’m going to have to use this in the future, Thanks!
This looks awesome, I’ll take a look! 😄
I don’t know if you’d count autotools and C as modern, but I found GNU Hello to be a nice starting point.
At $work, we used autohell for a few months. I ended up hand-rolling a configure script that suits modern *nix quite nicely. I now use it as a base for personal projects.
Just scanning over it:
The helptext says you can say
--prefix <directory>, but the actual argument-parsing code looks for--prefix=<directory>You check for the openssl binary, and later again for the header files; isn’t that a bit redundant?
You have a test to see is libev wants you not to link to
libm, but you also unconditionally link to it anyway.This is definitely a bug, thanks!
No, because somebody who has only the openssl package installed, needs to install the openssl-devel/-dev package.
I will look into this. I copied some of that from libev’s configure script, but it’s been a while.
Thanks for the feedback!
Edited because I pressed post instead of Preview
Right, but the
-devpackage will always depend on the binary package, so you can just check for the header.Ah, I see what you’re saying now. Thanks again!