[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdevelop-bugs
Subject:    [Bug 298812] Recognize #cmakedefine as valid syntax
From:       John <john5342 () gmail ! com>
Date:       2012-04-28 18:36:39
Message-ID: bug-298812-40295-gurQtFwsXn () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=298812

--- Comment #3 from John <john5342@gmail.com> ---
(In reply to comment #1)
> such config files are seldomly edited (at least in the usecases I can think
> of), hence marking as VLO

More mature projects i agree. Newer projects and especially mostly header
projects where build time configuration can't just be passed directly to the
compiler i have found these files change quite a bit. I do however agree that
some red underlining due to a feature which is not real C++ is hardly a high
priority.

> extending our language plugin with such toolchain specific stuff would also
> taint our code and make it potentially harder to maintain, so I'm not sure
> that we really should do this.

It is toolchain specific, although CMake is the default and probably best
supported build system used in KDevelop. I understand your reasoning though.

(In reply to comment #2)
> #cmakedefine is not meant to be used this way, but in small config.h files
> that are generated in build time.

I am well aware how to use this feature. The fact is though that whenever any
new build time configuration is required (new optional dependencies, new
platforms, etc, etc) somebody needs to edit the input file for config.h (e.g.
config.h.in). config.h.in is basically a normal header files except it is
primarily macros and also contains variable placeholders that configure_file
fills in. Currently if editing config.h.in is just a sea of red underlining and
completion of those macro names are broken for the remainder of the file.

> If you want to use those, generate .h files and include them in your
> projects normally.

I do include the generated file as is the whole idea behind it. However it is
the input file that needs to be edited and not the generated one.

It's no biggy anyway. It was a minor annoyance that i thought would be fairly
easy to sort. I have plenty of more personal patches in my private branch
anyway so when i get around to this myself i can just add it to the list.

Thank you both for your time and i appreciate the excellent IDE is resulting
from it. :-)

-- 
You are receiving this mail because:
You are the assignee for the bug.

_______________________________________________
KDevelop-bugs mailing list
KDevelop-bugs@kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-bugs
[prev in list] [next in list] [prev in thread] [next in thread]