3

Windows 7 で MUnit 2.1.2 と Haxe 3.2.1 を使用して、HaxeFlixel ゲーム (フラッシュ ターゲット) 用に自動生成されたサンプル テスト ( standard で作成し、with または without でhaxelib run munit gen実行) をコンパイルしようとしています。haxelib run munit t-coverage

HaxeWrapper.hx:73: --macro:1: character 0 : Invalid package : subfolder should be <empty>

...ここsubfolderは私のメインsourceディレクトリのサブフォルダです。ゲーム自体は、パッケージsubfolder.*(およびその他)への参照を使用して正常にコンパイルされますが、名前空間が単に.subfolder.nestedsubfolder.*sourcepackage;

指定された行番号は、プロジェクト内で何を修正する必要があるかを正確に示しているわけではありません...HaxeWrapper.hxを（頭上で）掘り下げる前に、これはサブフォルダー/異なるパッケージ名を持つ既知の問題ですか？プロジェクトか何か？

ところで、これが起こらない別のプロジェクトがありますが、そのプロジェクトにsourceは1つのサブフォルダーしか含まれておらず、そこにあるすべてが同じパッケージ名前空間(つまりpackage subfolder;.)を共有しています。（したがって、私の質問です。）

アップデート

手動テストの測定基準のためだけに、以前に自分のプロジェクトでも mcover を使用していました。それ以来、それは大きくなり、その結果、パッケージのサブフォルダーに整理しました。その間、デバッグ中のステッピングがより面倒になったため、mcover を有効にして試したことはありませんでした。mcover を再度有効にすると、プロジェクトがコンパイルされず、上記と同じエラー メッセージが表示されますが、HaxeWrapper.hx:73:プレフィックスはありません。

4

1 に答える 1

3

subfolderこれは、ファイルをそれらなしで自動生成していることを意味すると思いますpackage subfolder;。以前に mcover について聞いたことがありませんが、コードによって Haxe がファイルシステムで Haxe クラス ファイルを検索し、そのファイルpackageにパスに一致するステートメントがないことを Haxe が検出した時点で、同様のエラー メッセージが生成されるようです。 Haxe で見つけました。ただし、予想とは異なるエラーが発生します。

予想されるエラーの例

subfolder/MyClass.hx:

class MyClass {
  public static function main() {
    Sys.println("hi");
  }
}

出力：

>haxe -cpp x.cpp subfolder.MyClass
Invalid commandline class : subfolder.MyClass should be MyClass

これは、にアクセスしようとしたときに表示されると予想されるエラーですMyClass。ただし、この役立つエラー メッセージは、Haxe が最初にエントリ ポイントとして指定されたクラス名を解決しようとしたときにのみ表示されるようです。

同じ原因、別のエラー

subfolder/MyClass.hx上記のようにまだあると仮定して、適切なpackageステートメントで新しいクラスを追加します。

subfolder/AnotherClass.hx:

package subfolder;

class AnotherClass {
  static function main() {
    MyClass.main();
  }
}

出力：

>haxe -cpp x.cpp subfolder.AnotherClass
subfolder/AnotherClass.hx:5: characters 4-11 : Invalid package : subfolder should be <empty>

AnotherClass.hx:5:5(characters 4-11インデックスが 0 のように見えますか?)に行くと、 が表示されますMyClass。したがって、実際に窒息しているのは、ロードすることを期待していたという事実ですがsubfolder.MyClass、モジュールをロードした後、モジュールはステートメントMyClassがないため、完全修飾名であると主張しました。package

質問への適用

だから、私の推測では、あなたの mcover はpackageステートメントを欠いているファイルを生成しています。-namespaceorのようなオプションがある場合は、ではなくディレクトリ-root-packageを分析するように指示できる場合は、パフォーマンスが向上する可能性があります。に渡した値以外の値を mcover ツールに渡していますか?../subfolderhaxe -cp

mcover の機能に基づく別のアイデアは、不足しているプロジェクト内の .hx ファイルを参照しているということですpackage subfolder;。AnotherClass.hxを呼び出さないように変更すると、 をエントリ ポイントとしてMyClass.main()使用して正常にコンパイルできます。subfolder.AnotherClassHaxe はMyClass.hx、分析している他のコードによって参照されていない場合、解析/読み取りを試みようともしないようです。カバレッジ ツールを使用すると、ツールは発見したすべてのファイルを参照するコードをラップ/自動生成しようとする場合があります。Haxe 自体が通常はコンパイルすらしないファイルも含まれます。もちろん、これのポイントは、どのコードがまったくカバーされないか、決して実行されないかを理解することです;-)。

要するに、エラー メッセージで参照されているソース コードの場所でクラス名を見つけ、そのクラス名に.hx基づいて Haxe がロードするファイルを調べると、欠落しているpackageステートメントが見つかる可能性があります。エラーにソースコードの場所がない場合に何ができるかわかりませんが。

于 2016-10-09T21:15:42.670 に答える