On Mon, 17 Nov 2008 19:07:36 +1100, "Lex Trotman" elextr@gmail.com wrote:
2008/11/17 Enrico Tröger enrico.troeger@uvena.de
On Fri, 14 Nov 2008 12:00:54 +1100, "Lex Trotman" elextr@gmail.com wrote:
Hey,
reading your answer tells me I was too rude in my last mail, this was not intended.
No offense taken and I hope none caused by my reply.
As I understand it the options you are offering are:
- leave is_c_header() in and magically header files have no
commands available. As I have explained at length before this is a poor solution for some users.
I never wanted to actually suggest that. If I did so, sorry. The reason why is_c_header() exists is because I/we thought nobody will ever compile a header file. Since this assumption seems to be wrong, we should remove this function.
My misunderstanding, I thought you wanted to keep it, no problem.
- take is_c_header() out and all the C/C++ language commands are
available. Compiling depends on the accident that the command for compiling headers is the same as for source. It is for gcc but not for other compilers. Also 'build' is available and will overwrite the file.o from file.cpp with the pre-compiled header from file.hpp. Wrong and confusing
Ok, I didn't know that you actually need special compiler commands. But one of your goals was to allow setting multiple (up to three, IIRC) filetype related build commands. So, an user can set one of those commands to compile header files. And voila, we are done. But I guess you will tell me that I'm wrong again and I forgot about anything.
Well its possible, but if there is no distinction between headers and sources then the user has lost one of the commands for their sources because they have configured it into a header command. Whilst we could
I don't think this(using one build command for headers) would be such a big problem but I also don't compile headers usually. I still don't like the source/header separation. See Nick's and my response later on in this thread.
easily add an extra command, making it simple to implement, and it will work, I still worry that it isn't a very good one from the users point of view because even if we add an extra command there is still the problem of other source commands doing the wrong thing if invoked for headers. eg the standard source build command 'g++ -Wall -o "%e" "%f"' if invoked on a header, will overwrite the executable with a pre-compiled header file with the executable filename. Luckily on
Ouch. Sorry, I didn't think of PCH since I never used them before. If you compile an header normally, it would fail because there is no main () and if there is a main() implementation that it's really not a header. But this is not true anymore with PCH which also compile without a main(). We should not forget that the user is at some point also responsible for what he is doing and we can't/shouldn't prevent any possible mistake he could do.
But please keep in mind to keep the whole stuff simple. Nobody wants to
read 5 paragraphs in the manual just to compile a file.
This is a good point,my intention is that from a user point of view there will be little changed, so I will look at re-arranging my changes to the build-system part of the manual as follows:
- first a short description of how to use the build system with
supplied defaults without too much reference to details. This will cover maybe 70% of the users. (Linux gcc, windows Mingw users I think) 2. then a more detailed description of the system including project building and configuring the commands via the GUI. Should cover most of the rest of the users 3. if there is anything not configurable by GUI then it can go in an appendix for the hard core tinkerers
Sounds reasonable, I like the idea of splitting the whole description. 1. sounds like the famous 'for the impatient people' sections :).
Regards, Enrico