4 ms·

>Do open source projects have an obvious "run this script to configure your complete dev environment in respect to this project" ? ./configure

PeterisP 5y ago
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.
adwn 5y ago
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.
- adwn 5y ago
  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) ...
- whoopdedo 5y ago
  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."
  - adwn 5y ago
    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.

PeterisP 5y ago

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.

adwn 5y ago

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.

adwn 5y ago
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) ...
whoopdedo 5y ago
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."
- adwn 5y ago
  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.