After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 747582 - Clang command line options are relative to the wrong directory
Clang command line options are relative to the wrong directory
Status: RESOLVED FIXED
Product: gnome-builder
Classification: Other
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: GNOME Builder Maintainers
GNOME Builder Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-04-09 19:33 UTC by Giovanni Campagna
Modified: 2015-04-11 00:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
makecache: add support for out-of-tree, non-recursive automake (7.72 KB, patch)
2015-04-10 11:19 UTC, Christian Hergert
committed Details | Review
makecache: operate on all relative paths (1.11 KB, patch)
2015-04-10 23:58 UTC, Giovanni Campagna
committed Details | Review

Description Giovanni Campagna 2015-04-09 19:33:43 UTC
Command line arguments of the form -Isomething are relative to the builddir, but clang interprets them as relative to the directory that has the source file, which is wrong in case of out of tree builds or in case of non-recursive makefile.

Unfortunately I did not find how to convince clang to resolve relative paths differently, which means that builder would have to parse through the different options for relative -I and resolve them manually.
Comment 1 Christian Hergert 2015-04-09 19:35:56 UTC
(In reply to Giovanni Campagna from comment #0)
> Command line arguments of the form -Isomething are relative to the builddir,
> but clang interprets them as relative to the directory that has the source
> file, which is wrong in case of out of tree builds or in case of
> non-recursive makefile.
> 
> Unfortunately I did not find how to convince clang to resolve relative paths
> differently, which means that builder would have to parse through the
> different options for relative -I and resolve them manually.

Ugh. Sounds fun.

Builder mostly uses non-recursive automake and things work fine though?
Comment 2 Giovanni Campagna 2015-04-09 19:39:17 UTC
No, non-recursive automake makes it worse.
In builder it mostly works because stuff happens to be in the same directory (and automake has -I. by default, or it gets included with ""). But if you look eg. at libide/clang/ide-clang-service.c you get a fatal error including "ide-build-system.h", because -Ilibide/ does not work.
Comment 3 Christian Hergert 2015-04-09 19:41:54 UTC
Aha! Lovely. I'll see what I can do.
Comment 4 Christian Hergert 2015-04-10 11:17:55 UTC
This was a fun one!

Thanks for reporting, I tested using the gnome-builder tree both in and out of tree
and things seem to work well. Go ahead and let me know how it works for you on
any other projects.
Comment 5 Christian Hergert 2015-04-10 11:19:14 UTC
Created attachment 301273 [details] [review]
makecache: add support for out-of-tree, non-recursive automake

When attempting to resolve the CFLAGS, resolve relative paths so that
clang can find the files appropriately. Clang expects that the CFLAGS
are relative to the source file.
Comment 6 Giovanni Campagna 2015-04-10 23:48:49 UTC
Review of attachment 301273 [details] [review]:

You're an awesome person, did I ever tell you?

::: libide/autotools/ide-makecache.c
@@ +767,3 @@
+   */
+
+  if (g_str_has_prefix (part2, "./"))

Almost.

For config.h, automake uses -I., so this needs to be has_prefix("./") or == "."
Indeed, after the patch it fails only with config.h, everything else works.

(Test case: src/gedit/gedit-menu-stack-switcher.c in gnome-builder)

Also you should probably use g_build_filename() instead of g_strdup_printf()
Comment 7 Giovanni Campagna 2015-04-10 23:58:13 UTC
Created attachment 301339 [details] [review]
makecache: operate on all relative paths

Not just those starting with ./
Relative paths can start with ., .., or just a directory name.
The only distinguisher is that they don't start with /
Comment 8 Giovanni Campagna 2015-04-10 23:58:44 UTC
With this it works on all files in gnome-builder, and it works in libgweather, which uses recursive automake and -I.. to find config.h.