[QBS] Problem with retrieving artifacts in generator.

Jake Petroules jake.petroules at petroules.com
Sat Aug 2 10:29:36 CEST 2014


On 2014-08-02, at 03:48 AM, mapron <mapron at yandex.ru> wrote:

> i am started to rewrite MSVS generator.
> 
> 1) I've checked out   https://codereview.qt-project.org/#/c/89972/13
> 2) compiled qbs, set up toolchains and qt profiles;
> 3) from <qbs>/bin path executing command:
>> qbs generate -g MSVS2010 -f ../qbs.qbs profile:qt4 release debug
> 4)
> I use such test code in MsvsGenerator:
> 
> static QString buildVariant(const qbs::Project &project) 
> {
>    return project.projectConfiguration()
>        [QLatin1String("qbs")].toMap()
>        [QLatin1String("buildVariant")].toString();
> }
> void MsvsGenerator::generate()
> {
>    foreach (const Project& project, projects()){
>        qDebug() << "project file location:" << project.projectData().location().filePath();
>        qDebug() << "build variant:" << buildVariant(project);
>        qDebug() << "profile:" << project.profile();
>        foreach (const ProductData& pd, project.projectData().allProducts() ) {
>            qDebug() << "product:" << pd.name() << pd.location().filePath() << pd.targetName()
>                     << " targetsCount:" << pd.targetArtifacts().size();
>            foreach (const GroupData& gd, pd.groups()){
>                // properties are empty, nothing intresting.
>                // qDebug() << "group:" << gd.properties().allProperties();
>            }
>        }
>    }
> }
> 
> I've noticed:
> a) When running command line, sometimes it crashes (only release mode, so i could n't provide more info). When i passed only one configuration (one variant and profile), it doesn't.

Most likely a problem in your VS plugin code. Attach a debugger and see if you can track it down.

> b) targetCount is always zero. So i could not determine destination or installation directories, how to do this? it's important to debugger (qbs run command not suitable).

IIRC you have to build the project first? I don't remember, I will have to look (or ask Jörg/Christian).

> c)  we can only fetch filePaths, not their tags. That's why we have to duplicate "filters/tags" logic. It's undesirable.

For input files, you mean? Yes, we definitely need some new APIs to access file tags data.

> d) how could i get additional options from user? e.g.:
> -generated solution destination path, and maybe filename;

You should generate the solution in the base build directory, i.e.:

qbs::Project p;
QDir baseBuildDirectory = p.projectData().buildDirectory();
baseBuildDirectory.cdUp();

The base filename of the solution should be p.projectData().name() + ".sln" and similarly the projects can be qbs::ProductData::name() + ".vcproj"

> -generated projects output directory;

...same as above. Since we can automatically generate sensible names for these things I'm not sure there's much point to provide a means to override them, unless you can think of a good reason / use case to do so?

> -version of MSVC toolchain, project format version and various "v120_xp" suffixes and variations... for now i determine that by different generator names. Is it ok to return over 9000 kind of ProjectGenerator objects?

I think it's fine to have a separate named generator for each major VS release. [msvc2008, msvc2010, msvc2012, msvc2013]. Beyond that, extra thought is needed. We could perhaps introduce additional command line options to use specialized toolchains like vs120_xp and so on. How to scope these potential extra options to specific generators is an interesting problem, too. Certainly not all generators will use the same options.

> e) xcode and msvs generators created as static variable in heap of dll.
> static qbs::ProjectGenerator* generators[] = { new qbs::XcodeNativeGenerator(),	 ...
> then it returned as pointer...  all generators placed as pointers in m_generators. Seems valid at this point.
> Then in generate() command-line method, it placed in scoped pointer, which remove ONE of that generators... is it correct? maybe we should delete all such objects?
> i wondered just because when i created Generator object as plain static object (no heap), it caused heap corruption.

Whoops, I shouldn't be deleting that pointer as it's not owned by the caller there. Good catch, I'll go fix that.
-- 
Jake Petroules - jake.petroules at petroules.com
Chief Technology Officer - Petroules Corporation


More information about the Qbs mailing list