6 ms·

Understanding the process of building has zero to do with knowing how to type make, or knowing the exact command line parameters GCC needs. Confusing a few cli

Understanding the process of building has zero to do with knowing how to type make, or knowing the exact command line parameters GCC needs. Confusing a few cli commands with the process of building is just as bad as believing in the big magic button.

ajross 14y ago
Of course. But one environment scales and the other doesn't. A IDE user who only knows how to modify projects by adding files and clicking checkboxes for optimization settings will do that for the rest of their career. A CLI user who needs to edit makefiles will eventually have a vastly more powerful tool in the shed.
- cooldeal 14y ago
  >A CLI user who needs to edit makefiles will eventually have a vastly more powerful tool in the shed That is true if the user didn't already give up and leave programming completely due to the obtuseness and complexity of autotools,makefiles, m4,macros and workarounds like cmake.I survived it, but many others in my Masters class did not. http://esr.ibiblio.org/?p=1877 http://esr.ibiblio.org/?p=1877 If even ESR finds them troublesome, what hope does a beginner have? >Of course. But one environment scales and the other doesn't. A IDE user who only knows how to modify projects by adding files and clicking checkboxes for optimization settings will do that for the rest of their career Using an IDE does not mean that you cannot do advanced configuration, including setting options that change the commandline of the compiler used. Don't almost all GUIs call commandline compilers on the backend? Visual Studio even shows you the commandline being used when you hit the Build button. SQL Server usually has a "Script" button to generate script for a admin GUI option and you can do anything you can do in the IIS GUI with Power Shell. The power should be there for when you need it, but making everyone go through arcane options has the unfortunate side effect of making the tool less popular though it does show the power of the tool to the novice user.
  - ajross 14y ago
    This is the kind of discourse that shows the disconnect. I'm sorry, but programming is complicated. You're seriously claiming that someone who can intelligently navigate the rats nest that is the J2SE library environment can't handle autotools (and for the record: autotools really isn't what I'm talking about)? Please. It's just laziness and aesthetics. One looks shiny and new, and the other crufty and old. People like to play with shiny new toys. And, sigh, "advanced configuration" is certainly something more than setting compiler flags. That was sarcasm, intended to show the limit that IDE users hit trying to extend their tools. For a practical example, how about this: conditionally build the modules of your C/C++ project such that they can be either linked in statically to the main binary or loaded dynamically, and generate both versions in a standard build. Someone who knows how the linker works and how to write a makefile can do this in a day, easily. Someone who only knows the IDE will be lost; there's no button for that. They'd probably hack up some monstrosity involving thousand-line boilerplate like building all the modules as separate subprojects or some nonsense.
    - marmaduke 14y ago
      > programming is complicated I'd like to hide in the corner and applaud the recognition of this reality. I grew up with Windows, I've been learning cli and vim and ... for 5 years and I still suck. But as Kennedy said, "don't wish for easy lives, wish to be strong [wo]men."
  - msbarnett 14y ago
    >> Of course. But one environment scales and the other doesn't. A IDE user who only knows how to modify projects by adding files and clicking checkboxes for optimization settings will do that for the rest of their career > Using an IDE does not mean that you cannot do advanced configuration, including setting options that change the commandline of the compiler used. Don't almost all GUIs call commandline compilers on the backend? That's really illustrating his point, rather than countering it. If all you think of in terms of "advanced configuration" is "setting options that change the command line of the compiler", you're missing entire worlds of flexibility and productivity wins because of this GUI-centric view of things. What about, say (and this is a very trivial illustration of flexibility), compiling part of the project, running a tool that analyzes those .o files along with some network resources, which generates yet more source files, which are then picked up by another step in the same build process and linked into the final executable? I had to build essentially that kind of build system a few years back, for two different ecosystems, so that they could share some common infrastructure in a Big Org™ (a command-line/unix/ant-based Java build system, and a Windows/Visual Studio 2003/2008 based C# build system). The Java version was straightforward, but the Visual Studio version was an exercise in frustration. The IDE Gods grant you no "custom build step that will generate an unknown number of files with unknown names which you will then pick up and compile as part of this compilation process" button to press. They give you a build scripting language, MSBuild, but it's so crippled by the baked-in assumptions of its IDE-bound design that it won't get you anywhere (to be specific, it assumes that you can hardcode the name and path of every file to be compiled by the project. It will let you insert a wildcard, but it expands them when the IDE opens the project file, which is useless when files are generated during the build, and if anyone deletes a file from the project in the IDE, it will "helpfully" rewrite the wildcard into separate entries for everything the wildcard matched back when the IDE opened the project file. Pure crap). And this is a really trivial way to use the flexibility that the unix build environment gives you. There's so much more that can be automated than any IDE could hope to present a GUI for.
- j_baker 14y ago
  Indeed. But these tools can (and some might argue should) be learned outside of school. On what basis do you make the claim that make should be taught in school? I can count the number of times I've had to edit makefiles as part of my job on one hand, and I don't think I'm odd.
  - ajross 14y ago
    Everything is best learned by self study. School should expose you to the different choices in life. We expect doctors to have a good grounding in the practice of chemistry even though they'll never do a lab test themselves. Also: I'm not following. The context of your post implies that you agree with me, but the facts seem to say you're an IDE user. How can you possibly be doing development without modifying your build system? If you're not using make, you're using something else. My guess is it's an IDE...
    - j_baker 14y ago
      Actually, quite the opposite. I'm not sure I agree that students need to be informed of how to write build files, but I don't use an IDE myself. That said, I did learn how to program in an IDE, and I don't feel as though I missed out on a whole lot in doing so.
- joe_the_user 14y ago
  I'm using the Qt Creator IDE right now, in Linux of all places. The Desktop GUI I'm making involves about twenty libraries, multiple threads and other complexities. I could make my job even more complex by diving in and learning a command-line way to do everything. But it seems to me, my personal approach is, I move ahead by dealing with the necessary complexity and letting the unnecessary complexity fall away. I mean, I'm sure there a way use ls with wildcards in a way that doesn't puke all subdirectories out at you when you're trying to find a single file in a large directory. But the fact that ls does this by default seems like strong evidence that the interface wants you to remember random bs - indeed, I've read stuff here where people were saying essentially "vi is good because it makes me remember arbitrary commands, strengths your brain". It might even be true that it strengths your brain but I think only a subset of even geeks want to relate to their computers like this and this subset isn't the same as geeks who can create useful and powerful programs or the most productive subset. Also, I don't see any inherently more powerful tools here. Qt Creator can show me the meaningful references to variable foo, excluding comment "foo". I can't see grep doing that (even though I use grep for some thing but I still memorize ten cli options). All the tools are pretty Turing complete if you dig so it's hard to claim one thing is more powerful than another.
  - ajross 14y ago
    First off: clearly you're right. IDE's are very large, featureful software and there are lots of specific tasks they accelerate that you won't find addressed in the common CLI workflow. Finding "references to foo" is a good example. But here's some stuff Qt Creator can't do (or rather, provides no particular support for -- you can always use it as a text editor, of course): iOS apps; Android apps; sending email automatically; kernel drivers; languages other than C++ or Javascript: Scala, Haskell, TCL, C#, sh, perl, prolog, lisp...; build and deploy a node.js app; fire up an AWS instance; build a binary for an AVR microcontroller and download it to a device; Verilog or VHDL editing/synthesis/verification. Obviously I could go on and on, but you get the point. The command line environment? Yeah. It "does" all that stuff. And it does it in the same way. A Makefile for your VHDL project is going to look like a Makefile for your web app. The build scripts for your machine learning rig and your AVR hackery work the same way. You write your email in the same editor you use to write your C++ and CoffeeScript (and that you used 20 years ago to write your TCL!). So sure: if you want to spend your career searching for "foo" in your Qt C++/QML projects, Qt Creator is a great choice. And the next environment you work in will have a new tool, that does all the same boring stuff in mostly the same ways, and you'll need to learn it again. Pick up the command line and get better at it and you'll find you've opened up a much bigger door (and you won't need to learn to use a new editor every year, to boot). Is it clear now why there are some of us (with decades of make and shell and ssh in our toolbelts) who sit here and scratch our heads at the perpetuation of this nonsense?
- gutnor 14y ago
  > A IDE user who only knows how to modify projects by adding files and clicking checkboxes for optimization settings will do that for the rest of their career. Sorry, but seriously that is BS. I started coding with Basic on a Commodore 64. By the same reasoning, I should be mystified by a mouse. People learn, tools and languages evolve, especially during the whole span of a 40 years career.
ori_b 14y ago
Exactly. With my typical setup, a makefile looks like this: BIN=my-program OBJ=file1.o file2.o file3.o DEPS=../foo/libfoo.so -include ../config.mk include ../mk/c.mk include ../mk/lexyacc.mk It's not hard to modify, it's flexible, and if I need custom scripts to generate files, it's very easy to extend. I don't have to futz with compiler options, command line parameters, etc. I just add the next .o file to the list, and get back to coding. There's room for improvement, but it works for me. And it's implemented in less than 100 lines of make.
- lmm 14y ago
  Most makefile projects end up with a simple list of files to add to. But each one does it in a slightly different way, because make is basically an unstructured shell-scripting language. I can barely stand to work on projects that don't use maven any more. Declare your dependencies and your sources in a standard format that every other project uses, and then get on with actually writing code; the build system is not the place for arbitrary complexity.
  - ori_b 14y ago
    Make is a way of defining dependencies. It's relatively far from a free-form shell like language.

ajross 14y ago

Of course. But one environment scales and the other doesn't. A IDE user who only knows how to modify projects by adding files and clicking checkboxes for optimization settings will do that for the rest of their career. A CLI user who needs to edit makefiles will eventually have a vastly more powerful tool in the shed.

cooldeal 14y ago
>A CLI user who needs to edit makefiles will eventually have a vastly more powerful tool in the shed That is true if the user didn't already give up and leave programming completely due to the obtuseness and complexity of autotools,makefiles, m4,macros and workarounds like cmake.I survived it, but many others in my Masters class did not. http://esr.ibiblio.org/?p=1877 http://esr.ibiblio.org/?p=1877 If even ESR finds them troublesome, what hope does a beginner have? >Of course. But one environment scales and the other doesn't. A IDE user who only knows how to modify projects by adding files and clicking checkboxes for optimization settings will do that for the rest of their career Using an IDE does not mean that you cannot do advanced configuration, including setting options that change the commandline of the compiler used. Don't almost all GUIs call commandline compilers on the backend? Visual Studio even shows you the commandline being used when you hit the Build button. SQL Server usually has a "Script" button to generate script for a admin GUI option and you can do anything you can do in the IIS GUI with Power Shell. The power should be there for when you need it, but making everyone go through arcane options has the unfortunate side effect of making the tool less popular though it does show the power of the tool to the novice user.
- ajross 14y ago
  This is the kind of discourse that shows the disconnect. I'm sorry, but programming is complicated. You're seriously claiming that someone who can intelligently navigate the rats nest that is the J2SE library environment can't handle autotools (and for the record: autotools really isn't what I'm talking about)? Please. It's just laziness and aesthetics. One looks shiny and new, and the other crufty and old. People like to play with shiny new toys. And, sigh, "advanced configuration" is certainly something more than setting compiler flags. That was sarcasm, intended to show the limit that IDE users hit trying to extend their tools. For a practical example, how about this: conditionally build the modules of your C/C++ project such that they can be either linked in statically to the main binary or loaded dynamically, and generate both versions in a standard build. Someone who knows how the linker works and how to write a makefile can do this in a day, easily. Someone who only knows the IDE will be lost; there's no button for that. They'd probably hack up some monstrosity involving thousand-line boilerplate like building all the modules as separate subprojects or some nonsense.
  - marmaduke 14y ago
    > programming is complicated I'd like to hide in the corner and applaud the recognition of this reality. I grew up with Windows, I've been learning cli and vim and ... for 5 years and I still suck. But as Kennedy said, "don't wish for easy lives, wish to be strong [wo]men."
- msbarnett 14y ago
  >> Of course. But one environment scales and the other doesn't. A IDE user who only knows how to modify projects by adding files and clicking checkboxes for optimization settings will do that for the rest of their career > Using an IDE does not mean that you cannot do advanced configuration, including setting options that change the commandline of the compiler used. Don't almost all GUIs call commandline compilers on the backend? That's really illustrating his point, rather than countering it. If all you think of in terms of "advanced configuration" is "setting options that change the command line of the compiler", you're missing entire worlds of flexibility and productivity wins because of this GUI-centric view of things. What about, say (and this is a very trivial illustration of flexibility), compiling part of the project, running a tool that analyzes those .o files along with some network resources, which generates yet more source files, which are then picked up by another step in the same build process and linked into the final executable? I had to build essentially that kind of build system a few years back, for two different ecosystems, so that they could share some common infrastructure in a Big Org™ (a command-line/unix/ant-based Java build system, and a Windows/Visual Studio 2003/2008 based C# build system). The Java version was straightforward, but the Visual Studio version was an exercise in frustration. The IDE Gods grant you no "custom build step that will generate an unknown number of files with unknown names which you will then pick up and compile as part of this compilation process" button to press. They give you a build scripting language, MSBuild, but it's so crippled by the baked-in assumptions of its IDE-bound design that it won't get you anywhere (to be specific, it assumes that you can hardcode the name and path of every file to be compiled by the project. It will let you insert a wildcard, but it expands them when the IDE opens the project file, which is useless when files are generated during the build, and if anyone deletes a file from the project in the IDE, it will "helpfully" rewrite the wildcard into separate entries for everything the wildcard matched back when the IDE opened the project file. Pure crap). And this is a really trivial way to use the flexibility that the unix build environment gives you. There's so much more that can be automated than any IDE could hope to present a GUI for.
j_baker 14y ago
Indeed. But these tools can (and some might argue should) be learned outside of school. On what basis do you make the claim that make should be taught in school? I can count the number of times I've had to edit makefiles as part of my job on one hand, and I don't think I'm odd.
- ajross 14y ago
  Everything is best learned by self study. School should expose you to the different choices in life. We expect doctors to have a good grounding in the practice of chemistry even though they'll never do a lab test themselves. Also: I'm not following. The context of your post implies that you agree with me, but the facts seem to say you're an IDE user. How can you possibly be doing development without modifying your build system? If you're not using make, you're using something else. My guess is it's an IDE...
  - j_baker 14y ago
    Actually, quite the opposite. I'm not sure I agree that students need to be informed of how to write build files, but I don't use an IDE myself. That said, I did learn how to program in an IDE, and I don't feel as though I missed out on a whole lot in doing so.
joe_the_user 14y ago
I'm using the Qt Creator IDE right now, in Linux of all places. The Desktop GUI I'm making involves about twenty libraries, multiple threads and other complexities. I could make my job even more complex by diving in and learning a command-line way to do everything. But it seems to me, my personal approach is, I move ahead by dealing with the necessary complexity and letting the unnecessary complexity fall away. I mean, I'm sure there a way use ls with wildcards in a way that doesn't puke all subdirectories out at you when you're trying to find a single file in a large directory. But the fact that ls does this by default seems like strong evidence that the interface wants you to remember random bs - indeed, I've read stuff here where people were saying essentially "vi is good because it makes me remember arbitrary commands, strengths your brain". It might even be true that it strengths your brain but I think only a subset of even geeks want to relate to their computers like this and this subset isn't the same as geeks who can create useful and powerful programs or the most productive subset. Also, I don't see any inherently more powerful tools here. Qt Creator can show me the meaningful references to variable foo, excluding comment "foo". I can't see grep doing that (even though I use grep for some thing but I still memorize ten cli options). All the tools are pretty Turing complete if you dig so it's hard to claim one thing is more powerful than another.
- ajross 14y ago
  First off: clearly you're right. IDE's are very large, featureful software and there are lots of specific tasks they accelerate that you won't find addressed in the common CLI workflow. Finding "references to foo" is a good example. But here's some stuff Qt Creator can't do (or rather, provides no particular support for -- you can always use it as a text editor, of course): iOS apps; Android apps; sending email automatically; kernel drivers; languages other than C++ or Javascript: Scala, Haskell, TCL, C#, sh, perl, prolog, lisp...; build and deploy a node.js app; fire up an AWS instance; build a binary for an AVR microcontroller and download it to a device; Verilog or VHDL editing/synthesis/verification. Obviously I could go on and on, but you get the point. The command line environment? Yeah. It "does" all that stuff. And it does it in the same way. A Makefile for your VHDL project is going to look like a Makefile for your web app. The build scripts for your machine learning rig and your AVR hackery work the same way. You write your email in the same editor you use to write your C++ and CoffeeScript (and that you used 20 years ago to write your TCL!). So sure: if you want to spend your career searching for "foo" in your Qt C++/QML projects, Qt Creator is a great choice. And the next environment you work in will have a new tool, that does all the same boring stuff in mostly the same ways, and you'll need to learn it again. Pick up the command line and get better at it and you'll find you've opened up a much bigger door (and you won't need to learn to use a new editor every year, to boot). Is it clear now why there are some of us (with decades of make and shell and ssh in our toolbelts) who sit here and scratch our heads at the perpetuation of this nonsense?
gutnor 14y ago
> A IDE user who only knows how to modify projects by adding files and clicking checkboxes for optimization settings will do that for the rest of their career. Sorry, but seriously that is BS. I started coding with Basic on a Commodore 64. By the same reasoning, I should be mystified by a mouse. People learn, tools and languages evolve, especially during the whole span of a 40 years career.

ori_b 14y ago

Exactly. With my typical setup, a makefile looks like this: BIN=my-program OBJ=file1.o file2.o file3.o DEPS=../foo/libfoo.so -include ../config.mk include ../mk/c.mk include ../mk/lexyacc.mk It's not hard to modify, it's flexible, and if I need custom scripts to generate files, it's very easy to extend. I don't have to futz with compiler options, command line parameters, etc. I just add the next .o file to the list, and get back to coding. There's room for improvement, but it works for me. And it's implemented in less than 100 lines of make.

lmm 14y ago
Most makefile projects end up with a simple list of files to add to. But each one does it in a slightly different way, because make is basically an unstructured shell-scripting language. I can barely stand to work on projects that don't use maven any more. Declare your dependencies and your sources in a standard format that every other project uses, and then get on with actually writing code; the build system is not the place for arbitrary complexity.
- ori_b 14y ago
  Make is a way of defining dependencies. It's relatively far from a free-form shell like language.