As discussed in this Discord thread, currently the Group.prefix property doesn't require its value to end with a slash /. This leads to the following pros and cons.

Pros

• It's possible to use prefix to specify a part of the file name. For instance, having files like mac_autostart.hpp, mac_globalhotkeys.hpp, win_autostart.hpp, win_globalhotkeys.hpp, we could create a Group like this:

  Group {
      prefix: qbs.targetOS.contains('macos')? 'mac_' : 'win_'
      files: ['autostart.hpp', 'globalhotkeys.hpp']
  }
      

  At the same time, it can be quite confusing for a potential user of the project since there are no autostart.hpp and globalhotkeys.hpp files on the file system. So, a better way of handling this would be:

  Group {
      files: ['autostart.hpp', 'globalhotkeys.hpp'].map(function(fileName) {
          return (qbs.targetOS.contains('macos')? 'mac_' : 'win_') + fileName
      })
  }
      

  because it provides a clearer intention and doesn't split the real file names into two separate properties (although it's longer in terms of lines of code).

Cons

• Most of the found usecases for `prefix` are limited to using some directories and not part of the filenames. The only found exception is here. However, a user has to ensure the prefix ends with a slash in this case. If the prefix value denotes a directory but doesn't end with a slash, this leads to an invalid path.

  Group {
      prefix: project.sourceDirectory
      files: ['VERSION']
  }
      

  The result would be an invalid /home/me/my-projectVERSION.
  Also, if the prefix value already ends with a slash, but a user appends it manually like this:

  Group {
      prefix: project.sourceDirectory + '/'
      files: ['VERSION']
  }
      

  this would lead to a path with a double slash.
  The correct way of handling this can be the following:

  Group {
      files: [FileInfo.joinPaths(project.sourceDirectory, 'VERSION')]
  }
      

Proposal

I propose to declare the prefix property deprecated and to be removed by some future Qbs release. Instead, as proposed by arch, a baseDir property can be introduced with the following behavior:

• independently of whether the value of baseDir ends with a slash or not, the actual concatenation of baseDir and an element from files happens similarly to FileInfo.joinPaths, i.e., it puts a slash in-between only when necessary.