File naming may break CMake build (fails to link)

Bug #1005624 reported by Denis Declara on 2012-05-28
This bug affects 2 people
Affects Status Importance Assigned to Milestone

Bug Description

on some systems, cmake build may fail (linking phase), becouse of multiple files with the same name.
Tested on Arch Linux x86-64.
The affected files are:
 * ./src/print.h
 * ./src/extension/print.h
 * ./src/ui/dialog/print.h
Also Inkscape's CMake build maintainer (ideasman_42) advises to rename the files.
Attached you will find a patch attempting to fix the problem (based on revision 11432)

Denis Declara (declara91) wrote :
su_v (suv-lp) on 2012-06-01
Changed in inkscape:
status: New → Confirmed
Jon A. Cruz (jon-joncruz) wrote :

In general that sounds like it might not be the best solution. Needing source files to be unique regardless of their folder might cause us problems in the long run, and is not consistent with modern namespaced approaches.

su_v (suv-lp) wrote :

@ideasman42 - subscribing you to this report: maybe you can comment on other solutions to fix recent build failures with cmake?

su_v (suv-lp) wrote :

@Denis - can you confirm that it was a quite recent change in trunk which triggers this link failure with cmake (i.e. after 2012-05-05), and that your branch at its current pushed state (r11108) [1] still builds & links ok with cmake?

[1] <>

Denis Declara (declara91) wrote :

@suv - I can confirm, that my branch (r11108) still builds fine on my system, while the current branch (r11451) fails. I'm pretty sure that an older version of the trunk (early may) would build successfully (haven't had the time to test this yet...). In the meantime I've uploaded the build logs [1] of my branch and the trunk (with VERBOSE=1).

[1] <>

su_v (suv-lp) wrote :

> I can confirm, that my branch (r11108) still builds fine
> on my system, while the current branch (r11451) fails

Thanks. AFAIU Tthis means that a change in trunk between revision r11325 [1] and r11432 [1] causes the linking issues with cmake.

[1] last merge of trunk into your branch (May 5, 2012):

[2] current revision at the time you first asked about known issues with linking on irc (May 28, 2012)

Changed in inkscape:
importance: Undecided → Medium
su_v (suv-lp) wrote :

Link failure still present with current trunk (r11885) - confirmed by houz (via irc) on 64bit Debian Sid.

ideasman42 (ideasman42) wrote :

Hi - I havn't been paying full attention to this report,
I built with CMake/Ninja today and it worked fine.

as for naming files the same or not, I can see how duplicates should work and to rename only for this reason alone is not good.

But practically IMHO its just convenient - if you want to add a break point int gdb you can do "break foo.c:10" without getting the wrong file (for headers this is less an issue of course).
In IDE's its normally easier to select a file in the project when files are unique too.

Another thing which is a bit.... bad practice IMHO is having /src/ contain many files and then a duplciate name in a subdirectory.

./src/print.h <--- would rename this one.

Having each dir use its own includes and allow name collision seems ok but having files up the tree with the same name IMHO is a bit sloppy and asking for troubles --- even tho it can be made to work.

ideasman42 (ideasman42) wrote :

adding note, tested with r11888 which works.

su_v (suv-lp) wrote :

ideasman42 wrote on 2012-11-21
> I built with CMake/Ninja today and it worked fine.

JFTR - to build inkscape with cmake+ninja:
$ cmake ../inkscape -G Ninja

summary: - File naming may break CMake build
+ File naming may break CMake build (fails to link)
su_v (suv-lp) wrote :

Is this still an issue with CMake builds of current trunk (with or without ninja)?

Changed in inkscape:
status: Confirmed → Incomplete
Mc (mc...) wrote :

No activity, last tests seems to work => closing as invalid, please reopen if you still have a problem

Changed in inkscape:
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related blueprints