New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gnome: Add include_directories parameter to gtkdoc() #2603

Merged
merged 1 commit into from Nov 10, 2017

Conversation

Projects
None yet
4 participants
@xclaesse
Contributor

xclaesse commented Nov 9, 2017

It is already used by generate_gir(), and allow to fix nicely https://bugzilla.gnome.org/show_bug.cgi?id=786796

@jpakkane jpakkane merged commit 9e2d078 into mesonbuild:master Nov 10, 2017

3 checks passed

ci/sideci No issues found!
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@xclaesse xclaesse deleted the xclaesse:gtkdoc-include-directories branch Nov 10, 2017

@Salamandar

This comment has been minimized.

Show comment
Hide comment
@Salamandar

Salamandar Nov 17, 2017

Contributor

It seems buggy. While in the subdir devel-docs/libgimp, i write

gnome.gtkdoc('libgimp',
  …,
  include_directories: [
    include_directories('../..'),
  ],
  …,
)

The call to gcc (by scanobj) is :
gcc -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I./devel-docs/libgimp/.. -I../devel-docs/libgimp/.. -c -o libgimp-scan.o libgimp-scan.c

  • -I./devel-docs/libgimp/../.. should be -I./../..
  • -I../devel-docs/libgimp/../.. should be -I../../../../..

Because we already are in the devel-docs/libgimp directory !

EDIT : After some tests (and passing include objects from the root directory to prevent '../../'), it seems that @BUILD_ROOT@ and @SOURCE_ROOT@ in the cflags/args are replaced by '.', and not '../..' as it would be needed.

EDIT2 : Maybe in Meson all commands are run from BuildRoot. In that case, my first edit is not right. The problem may be that gtkdoc-scanobj internally cd the_subdir , thus breaking the relative path.

Contributor

Salamandar commented Nov 17, 2017

It seems buggy. While in the subdir devel-docs/libgimp, i write

gnome.gtkdoc('libgimp',
  …,
  include_directories: [
    include_directories('../..'),
  ],
  …,
)

The call to gcc (by scanobj) is :
gcc -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I./devel-docs/libgimp/.. -I../devel-docs/libgimp/.. -c -o libgimp-scan.o libgimp-scan.c

  • -I./devel-docs/libgimp/../.. should be -I./../..
  • -I../devel-docs/libgimp/../.. should be -I../../../../..

Because we already are in the devel-docs/libgimp directory !

EDIT : After some tests (and passing include objects from the root directory to prevent '../../'), it seems that @BUILD_ROOT@ and @SOURCE_ROOT@ in the cflags/args are replaced by '.', and not '../..' as it would be needed.

EDIT2 : Maybe in Meson all commands are run from BuildRoot. In that case, my first edit is not right. The problem may be that gtkdoc-scanobj internally cd the_subdir , thus breaking the relative path.

@xclaesse

This comment has been minimized.

Show comment
Hide comment
@xclaesse

xclaesse Nov 17, 2017

Contributor

In my testing I'm using include_directories('.') and it adds -I cflag with the full path.

Contributor

xclaesse commented Nov 17, 2017

In my testing I'm using include_directories('.') and it adds -I cflag with the full path.

@Salamandar

This comment has been minimized.

Show comment
Hide comment
@Salamandar

Salamandar Nov 18, 2017

Contributor

Yes but that's the problem : there should not be the full path. The compiler is called from within the subdir, so the -I cflags should not contain the full ptah.

Contributor

Salamandar commented Nov 18, 2017

Yes but that's the problem : there should not be the full path. The compiler is called from within the subdir, so the -I cflags should not contain the full ptah.

@xclaesse

This comment has been minimized.

Show comment
Hide comment
@xclaesse

xclaesse Nov 18, 2017

Contributor

In any case, the functionality is not implemented in this PR, it just enable code that was already there. If you think there is a bug you should open a new issue.

Contributor

xclaesse commented Nov 18, 2017

In any case, the functionality is not implemented in this PR, it just enable code that was already there. If you think there is a bug you should open a new issue.

@Salamandar

This comment has been minimized.

Show comment
Hide comment
@Salamandar

Salamandar Nov 18, 2017

Contributor

Will do !

Contributor

Salamandar commented Nov 18, 2017

Will do !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment