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

List:       kdevelop-bugs
Subject:    [Bug 172636] New: Automatic #include insertion support using the LSB
From:       Pantelis <pktoss () gmail ! com>
Date:       2008-10-12 6:32:21
Message-ID: bug-172636-40295 () http ! bugs ! kde ! org/
[Download RAW message or body]

http://bugs.kde.org/show_bug.cgi?id=172636

           Summary: Automatic #include insertion support using the LSB
                    SpecDB
           Product: kdevelop
           Version: unspecified
          Platform: Compiled Sources
        OS/Version: unspecified
            Status: UNCONFIRMED
          Severity: wishlist
          Priority: NOR
         Component: general
        AssignedTo: kdevelop-bugs@kdevelop.org
        ReportedBy: pktoss@gmail.com


Version:            (using Devel)
Installed from:    Compiled sources

You found a code snippet somewhere in the net and you paste it in your IDE. The
parser does not understand it because you haven't set the include paths and
libraries yet. So, now you have to set this stuff manually just to get an
example to work. This must get done like millions of times every day around the
globe.

As we all know, free software and standardization rock, so why not take
advantage of it to gain extra convenience?

The LSB people have done a lot of the foundation work needed to support such a
feature. They have a database where they enumerate all toplevel constructs
(functions, classes, global variables), #include files and libraries, even
associated with distribution versions and all.

So, the workflow would be that you set your distribution and its version
somewhere and when the parser finds an identifier use whose declaration cannot
be found it issues a simple mysql query to the database
and in 90% of the cases it will get the right answer.

The other 10% is if API code has changed from the last time the database was
updated, or if e.g., you are explicitly developing for an old version.

But the parser can always *verify* the correctness of the answer which is
easier than having to calculate the answer itself and the feature can
be turned off when developing for a platform where the database is known
to not contain.

Using the results of the queries kdevelop can auto-set the include files,
include paths, libraries, everything. Especially if you choose to create a
cmake-based project, pretty much all the boring build-system/include work can
be done for you and you can focus only on the important bit: the code.

They already have automatic scripts to keep this DB up-to-date and the way
parsing technology is evolving they will only get better at it.
Also, for the users that cannot spare a few hundred megs to store this
DB locally but would still like the benefits there is still hope (as
long as they have an unlimited net connection) since this query answering can
also be provided by a web service.

There is already the lsb navigator website but if we knew what it takes to
provide IDE support it is quite likely they would do it since they are not
funded by advertisements but by the linux foundation or something.

Even if we could get full autoinclude & auto-build support for say the 10-20
most common libraries/frameworks in the open source stack it would still be a
huge win.


-- 
Configure bugmail: http://bugs.kde.org/userprefs.cgi?tab=email
------- 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]