>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
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.
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.
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."
>> 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.
I call standard makefiles as a pre-build or post-build task in Visual Studio. The pre-build task even generates some source files that are subsequently used in the build.
Just make sure you have make.exe in you PATH and maybe defer the call to a batch file if it is too complex for VS. Or use the batch file to set up the PATH altogether.
Pre-build tasks wouldn't cut it, IIRC. The issue was that compiling the project required compiling part of it (part a), then generating source based on the results of (a), then building that generated source (which required the presence of the compiled results from (a), then compiling the rest of the project (b).
Unless I'm grossly misremembering, pre-build tasks would only have worked if the project had been broken up into separate projects such that the generation script could run post-(a) or pre-(b).
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 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.