[Geany-devel] C/C++ Header filetypes / templates

[Enrico Tröger]

On Mon, 17 Nov 2008 19:07:36 +1100, "Lex Trotman" <elextr at gmail.com>
wrote:

>2008/11/17 Enrico Tröger <enrico.troeger at uvena.de>
>
>> On Fri, 14 Nov 2008 12:00:54 +1100, "Lex Trotman" <elextr at 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:
>> >1. 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.
>
>>
>>
>> >2. 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:
>
>1. 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

-- 
Get my GPG key from http://www.uvena.de/pub.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20081117/37bf11d5/attachment.pgp>