On 05/17/2017 02:52 PM, bartc wrote: > On 17/05/2017 21:17, Michael Torrie wrote: >> On 05/17/2017 01:32 PM, bartc wrote: >>> Sometimes, if there's a problem. But usually the code is doing something >>> sensible. The stuff in configure is complete gobbledygook (if anyone >>> doesn't believe me, just have look). >> >> Well trying to edit an executable in a disassembler would look like >> gobligook as well. > > The content of configure is high-level human readable source code. But > it is meaningless.
No, I assure you, it's compiled code. Happens to be readable to those who know how to read it, but it was never written by a human. > <snip> > Yes. The end-result of all this might be something like: > > gcc -c file1.c > gcc -c file2.c > ... > gcc file1.o file2.o ... -opython.exe > > Someone please explain why I can't just do that You sure could if you were sure of the right order given dependencies (.h files). But it would be tedious if you had thousands of source code files. And what if you had a common header file depended on by hundreds of other files? You'd have to either manually identify each affected file and recompile it, or recompile the whole works again. For a large project, or even a medium-sized one, that's just not sustainable. Sure you could put more in a file, as you already do, and that works for small projects such as your compilers and also sqlite. Wouldn't work at all for the Linux kernel, of course. That said, there are huge benefits to keeping your source files short, modular, and as abstract as possible. And huge benefits to using a build manager program like scons, qmake, or even Visual Studio solutions, even to small programs. I tend to do the same as you for small, one-off programs. I just compile and link them with gcc manually. Since that fits your needs you can keep doing it. Eventually you may encounter the limitations of that, and then you can think about investigating a tool like scons. -- https://mail.python.org/mailman/listinfo/python-list
