FindIntltool.cmake GENERATED_POTFILES detection misbehaves with long build directory names

[James Henstridge]

The GENERATED_POTFILES logic seems to break if the path to the source file is shorter than ${CMAKE_BINARY_DIR}.

As a test, create a CMake project using FindIntltool with the following files in the base directory (they don't need to be part of any target):

    a.c
    aa.c
    aaa.c
    aaaa.c

I have the following in po/CMakeLists.txt:

    intltool_update_potfile(
        ALL
        KEYWORDS "tr" "tr:1,2" "N_"
        GETTEXT_PACKAGE "test"
        COPYRIGHT_HOLDER "foo"
        POTFILES_TEMPLATE "POTFILES.in.in"
    )

And po/POTFILES.in.in contains only "@GENERATED_POTFILES@".

I create a subdirectory "build", and run "cmake .." in it. Now the po/POTFILES.in file contains only aaa.c and aaaa.c.

If instead I use a shorter directory name for the build directory (e.g. by moving it outside of the source dir and keeping the name short), I will see more source files.

The problem appears to be in the _INTLTOOL_EXCLUDE_PATH function, where it excludes any file whose path name is shorter than the filter length.

I noticed this when using the Ubuntu SDK, which defaults to extremely long build directories when building for a kit.

[Pete Woods (pete-woods)]

Hmm. I'm not sure if it's about the length of the paths, as much as me stupidly excluding everything that's a child of the source tree. Including the binary directory!

[Pete Woods (pete-woods)]

No, scratch that comment. Just me being confused

[James Henstridge (jamesh)]

The condition within the loop of _intltool_exclude_path reads as follows:

        if(NOT (${_FILTER_LENGTH} GREATER ${_ABS_PATH_LENGTH}))
            string(SUBSTRING ${_ABS_PATH} 0 ${_FILTER_LENGTH} _PATH_HEAD)
            if(NOT ${_PATH_HEAD} STREQUAL ${FILTER})
                list(APPEND _TMP ${_PATH})
            endif()
        endif()

So in order for a path to be appended to the list, it must:

1. its length must be greater than or equal to filter_length
2. the substring of the path up to filter_length must not equal FILTER.

Here, FILTER is $CMAKE_BINARY_DIR, so any paths that are shorter will be excluded by (1). I think there should be an "else" clause on the outer "if" statement that also appends to the list.

[Pete Woods (pete-woods)]

This is my crappy "starts with" function being braindead, yes :(

[Launchpad Janitor (janitor)]

This bug was fixed in the package cmake-extras - 0.4+15.10.20150622.1-0ubuntu1

---------------
cmake-extras (0.4+15.10.20150622.1-0ubuntu1) wily; urgency=medium

  [ Michi Henning ]
  * Enable coverage with clang. If build type is coverage and clang is
    used, clang emits coverage data in gcc format, so gcovr/lcov can be
    used to generate the report.
  * Fixes carried over from thumbnailer, made by James to correctly
    filter XML coverage data, so we don't get tons of noise about system
    files in the coverage report created by Jenkins.

  [ Pete Woods ]
  * Install modules using CMake to allow detection of CMake version (LP:
    #1467030)

 -- CI Train Bot <email address hidden> Mon, 22 Jun 2015 08:55:27 +0000