2-cents

[GK]

I am willing to test/use when ready

thoughts

Do you think this might introduce a design consideration on the output
of pkg-config

It's possible that there may be/may arise other toolkit frameworks
that also rely upon an external command to provide includes, libs,
compiler and linker flags via a local command output. It is possible
to design so that the CDT interface is pkg-config command unaware

A newline(LF) separated list could be a external command independent
input format via some input in the CDT properties dialog.

The following option can easy gleaning of include directories
pkg-config --cflags-only-I gtkmm-30
lists only include dir flags

pkg-config --cflags-only-I gtkmm-3.0 | sed -e "s/-I//g" | xargs -n 1
echo
generates a list of directories, one on each line

subQ) What if GTK, gtkmm are installed in a path with a 'space' in it
as C:\program Files\GTK\include
what is pkg-config output in that situation ?

If the output of pkg-config were to change, one only needs to rework
the shell piped filtering to generate list correctly.

[Petri Tuononen]

Thanks for your comments. This surely raises some thoughts.

First of all what might make things worse is that shell commands differ
across OS's and this must be kept cross-platform.

Currently the OS is first checked and then the right pkg-config commands
find include paths, lib paths and libs + other gcc flags for given
package. Then the output is parsed to remove options (-I, -l, -L) and
form a list(s).

To make things easier a list of available packages are shown on a
property page. Checking a package executes necessary commands on the
background. The current design doesn't involve any knowledge of shell
commands from the end-user which I personally like.

Your idea of a more general approach sounds good but did you know that
you can already input commands directly to compiler? The only drawback
is that some shell commands of Unix tools don't work on Windows (e.g.
back ticks).

Maybe I miss something here.

Petri

On 27.5.2011 16:53, GK wrote:
> I am willing to test/use when ready
>
> thoughts
>
> Do you think this might introduce a design consideration on the output
> of pkg-config
>
> It's possible that there may be/may arise other toolkit frameworks
> that also rely upon an external command to provide includes, libs,
> compiler and linker flags via a local command output. It is possible
> to design so that the CDT interface is pkg-config command unaware
>
> A newline(LF) separated list could be a external command independent
> input format via some input in the CDT properties dialog.
>
> The following option can easy gleaning of include directories
> pkg-config --cflags-only-I gtkmm-30
> lists only include dir flags
>
> pkg-config --cflags-only-I gtkmm-3.0 | sed -e "s/-I//g" | xargs -n 1
> echo
> generates a list of directories, one on each line
>
> subQ) What if GTK, gtkmm are installed in a path with a 'space' in it
> as C:\program Files\GTK\include
> what is pkg-config output in that situation ?
>

Yet to be tested.

[GK]

You are correct, though there are ways to pass compiler flags
directly, by using build variables, the focus is to make eclipse
editor aware of the includes, so that it avoids the 'unresolved
includes' and undesirable effects there off. The only way currently to
make eclipse package aware is to enter includes and other things line
by line.

I have been thinking, Maybe what you're doing is sufficient too.
It seems like the general trend is for even non-gtk packages to create
a .pc file in
/usr/share/pkgconfig
/usr/lib64/pkgconfig (on a fedora-15 x86-64 system)

While one may state that it would be easy and general to use shell
commands to create a universally output readable plain vanilla list,
one can also state that it is equally easily create a .pc file for
whatever framework, Its a matter of time before every devel-package
creator to create .pc files on every platform. The .pc files, if not
provided, seem easy enough for any developer to make on their own too,
using whatever (shell) tools of choice.
meaning pkg-config is the desirable eventuality in which case CDT-pkg-
config integration is very sound.

diff topic: CDT seems to have the dual role of
a) being autotools aware and generating a Makefile
b) making eclipse IDE dependency aware, so that it assist intelligent
and graphically facilitated development.
I am mostly unaware of the more intricate eclipse-linuxtools stuff.
Simple java eclipse projects create a .settings, .project
and .classpath files.
The CDT has to make a makefile, I wonder if this makefile can be as
elaborate as those made with autoconf and automake. just a note,
nothing to say here.

diff topic: Another possible caution point. It might possible that
different build configurations may use . eclipse CDT properties. The
cdt-pkg-config integration will assist per-build-configuration as
compared to globally affecting all build configurations.

[Petri Tuononen]

Again, thanks for your thoughts.

I guess I could additionally use build variables, but generally I think
it's better if users can find the values added to tools as well (Paths
and Symbols tab). This is what users expect in my opinion. I will look
into it if the indexer is unable to resolve the values without using the
build variables.

FYI: Additionally you could post your ideas to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=44761 where this
pkg-config support feature is discussed amongst CDT developers. However
I am the only one to develop this but it sure helps if there is
discussion going on.

Petri

[Petri Tuononen]

On May 27, 4:53 pm, GK <hgkam...@gmail.com> wrote:
>
> I am willing to test/use when ready
>

Now I believe it is ready to be tested. Should work in most cases. If
not... that is why it should be tested :)

>
> What if GTK, gtkmm are installed in a path with a 'space' in it
> as C:\program Files\GTK\include
> what is pkg-config output in that situation ?
>

I am afraid that it is a feature of pkg-config that does not like
spaces on path names. I coded such that I quoted the path name, but
only the packages will be listed correctly. Options such as --cflags
will result in bad output.