That's not even close to being accurate. The real workflow looks more like this:

1) Install an appropriate compiler toolchain.

2) Install whatever other tools are needed (like pkgconfig).

3) Install the necessary *-dev packages for the library dependencies.

4) Figure out which options to pass to configure to include the features you want and exclude the features you don't want.

5) ./configure

6) Go back to step 3 because you had a wrong *-dev package version, or you missed a library you care about.

7) ./configure

8) make

9) Diagnose the error messages and scream in frustration, because the compiler you installed in step 1 is too old/too new/too not gcc.

10) Install gcc version x.y.z

11) ./configure

12) make

13) Get the same error messages, because you didn't deinstall the first compiler and configure helpfully selected it again.

14) Give up in disgust and let someone else fix the bug you found.

Sorry, I just realized that the above workflow is wrong: Since you want to fix a bug, you'll probably clone the development branch of the repo, which doesn't even have a configure script – only source releases have that. So prepend these steps:

0.1) Install the autotools.

0.2) Run autoconf, no wait, automake, no wait, autoreconf, no wait, autoreconf --install.

0.3) Delete all files in the directory and checkout a fresh copy.

0.4) autoreconf --install

1) ...

1 through 3 (I rarely encounter 6 and never 9) are baked into most OS installers and can be done once then saved as a VM or Docker image to be cloned. That level of pedantry is akin to saying "To compile the project applepie.io from scratch you must first create the universe."

Paraphrased:

    _carbyau_: Simple command to configure your complete dev environment in respect to this project" ?

    layoutIfNeeded: configure

    adwn: No, because ...

I don't see any pedantry on my part. Also, this:

> [...] and can be done once then saved as a VM or Docker image to be cloned

is like that infamous HN comment proclaiming that nobody needs Dropbox, because you can simply "get an FTP account, mount it locally with curlftpfs, and then use SVN or CVS on the mounted filesystem". The original question asked about a simple command to configure a complete environment.

If ./configure just would work for that project out of the box, that would be great, but it seems more like an exception, because usually it's not sufficient and it breaks on some dependency issues that are easily solvable if you know the dev environment and pretty much need mailing list assistance if you don't know how their project works and you just want to fix an off by one error.