В Unreal Engine 4.26.2 я пытаюсь упаковать проект смеси Blueprint / C ++ для Win64.
Однако я обнаружил следующую ошибку:
LogMainFrame: Project does not require temp target
LogLauncherProfile: Found promoted target with matching version at ../../../Engine/Binaries/Win64/UE4Game-Win64-Shipping.target
UATHelper: Packaging (Windows (64-bit)): Running AutomationTool...
UATHelper: Packaging (Windows (64-bit)): Parsing command line: -ScriptsForProject="C:/Users/Administrator/Documents/Unreal Projects/foo.uproject" BuildCookRun -nocompileeditor -installed -nop4 -project="C:/Users/Administrator/Documents/Unreal Projects/foo.uproject" -coo
k -stage -archive -archivedirectory=C:/Users/Administrator/Desktop/Win32UnrealBuilds -package -ue4exe="C:Program FilesEpic GamesUE_4.26EngineBinariesWin64UE4Editor-Cmd.exe" -ddc=InstalledDerivedDataBackendGraph -pak -prereqs -nodebuginfo -targetplatform=Win64 -clientconfig=Shipping -utf8output
UATHelper: Packaging (Windows (64-bit)): Setting up ProjectParams for C:UsersAdministratorDocumentsUnreal Projectsfoo.uproject
UATHelper: Packaging (Windows (64-bit)): ERROR: Game target not found. Game target is required with -cook or -cookonthefly
UATHelper: Packaging (Windows (64-bit)): (see C:UsersAdministratorAppDataRoamingUnreal EngineAutomationToolLogsC+Program+Files+Epic+Games+UE_4.26Log.txt for full exception trace)
PackagingResults: Error: Game target not found. Game target is required with -cook or -cookonthefly
UATHelper: Packaging (Windows (64-bit)): AutomationTool exiting with ExitCode=1 (Error_Unknown)
UATHelper: Packaging (Windows (64-bit)): BUILD FAILED
PackagingResults: Error: Unknown Error
Соответствующий раздел полной трассировки исключения:
BuildCookRun.SetupParams: Setting up ProjectParams for C:UsersAdministratorDocumentsUnreal Projectsfoo.uproject
InternalUtils.SafeFileExists: SafeFileExists C:UsersAdministratorAppDataLocalTempUATC+Program+Files+Epic+Games+UE_4.26RulesUATRules24283721.dll=False
DynamicCompilation.RequiresCompilation: Compiling C:UsersAdministratorAppDataLocalTempUATC+Program+Files+Epic+Games+UE_4.26RulesUATRules24283721.dll: Assembly does not exist
...
Program.Main: AutomationTool exiting with ExitCode=1 (Error_Unknown)
Есть ли обычная причина, по которой «Игровая цель не найдена» поражена?
1 ответ
Лучший ответ
Хотя неясно, почему это сработало, копирование файла projectname.Target.cs по умолчанию в каталог Source и переименование его projectnameGame.Target.cs (а также изменение внутреннего имени класса этого файла на соответствие), похоже, помогли обманывать. Теперь в каталоге Source находятся 3 файла Target.cs.
- имя проекта.Target.cs
- имя проектаGame.Target.cs
- projectnameEditor.Target.cs
В этот момент все снова заработало … это кажется странным, но работает!
1
Scott G
18 Май 2021 в 17:01
При запуске ряда современных игр (обычно это «CS:GO», «Titanfall 2», «Team Fortress» и ряда других) мы можем встретить уведомление «Only one instance of the game can be running at one time» и не понимать, каким образом это исправить. Игра при этом отказывается запускаться, а при перезапуске упомянутое нами уведомление появляется вновь. Причиной дисфункции обычно является запущенный ранее процесс игры, висящий в фоне и мешающий корректному старту программы. Ниже разберём суть возникшей ошибки, а также рассмотрим, как её удалить.
Содержание
- Причины возникшей проблемы
- Каким образом исправить ошибку перезапуском компьютера
- Прекращение процесса игры в Диспетчере задач
- Запуск игры с помощью правой клавиши мыши при ошибке «Only one instance…»
- Проверка кэш игры в Стим
- Переустановка игры для исправления проблемы
- Видео-инструкция
Причины возникшей проблемы
В переводе рассматриваемое нами уведомление выглядит как «Единовременно может быть запущена только одна версия игры».
Причинами появления указанного уведомления обычно является следующее:
| Причины ошибки: | Пояснение: |
|---|---|
| Пользователь каким-либо образом запустил игру ранее и её процесс остаётся запущенным в фоне. | В этом случае система препятствует повторному запуску игры. |
| Имеются ошибки в файле кэша игры. | Обычно возникает при скачивании из неизвестных источников. |
| Пользователь слишком быстро несколько раз кликнул на иконку игры. | Это инициирует её многоразовый запуск. |
| У пользователя установлена Виндовс 8. | А усугубляет проблему использование пиратской CS (не от Стим). |
Давайте разберёмся, каким образом можно исправить ошибку «Only one instance of the game…» на вашем ПК.
Читайте также: как решить ошибку «Unicode directory path not supported ошибка в КС:ГО».
Каким образом исправить ошибку перезапуском компьютера
Самым простым и тривиальным решение, позволяющим избавиться от ошибки «Only one instance…» будет стандартный перезапуск вашего ПК. Перезагрузите вашу систему, и запустите нужную игру вновь. Во многих случаях ошибка будет устранена.
Прекращение процесса игры в Диспетчере задач
Вторым эффективным решением, позволяющим устранить ошибку «Only one instance of the game can be running at one time» является прекращение процесса игры в Диспетчере задач. Для этого запустите Диспетчер задач (на Виндовс 10 достаточно одновременно нажать клавиши Ctrl+Shift+Escape), и просмотрите перечень запущенных процессов. Найдите там процесс игры, кликните на него, и внизу нажмите на «Снять задачу».
Для CS:GO такими процессами являются:
hl2.exe *32 (или 64)
csgo.exe
hl2.exe
и другие.
После прекращения процесса запустите игру стандартным образом.
Запуск игры с помощью правой клавиши мыши при ошибке «Only one instance…»
Во многих случаях появление сообщения «Only one instance…» может быть вызвано многократным единовременным запуском игры со стороны пользователя. В этом случае пользователь просто быстро несколько раз кликает на ярлык игры, вызывая её многократный запуск и появление рассматриваемого нами сообщения.
В этом случае рекомендуем перезагрузить ваш ПК. Затем наведите курсор мышки на ярлык игры, кликните раз на правую(!) клавишу мышки, и в появившемся меню выберите «Открыть».
Проверка кэш игры в Стим
Хороший способ решить ошибку «Only one instance of the game» — это проверить кэш игры в вашем Стим.
Каким образом это исправить:
- Запустите ваш Стим;
- Перейдите в его библиотеку и найдите там вашу игру;
- Кликните правой клавишей мышки на игре, и в появившемся меню выберите опцию «Свойства»;
- Выберите вкладку «Локальные файлы», и кликните на кнопку «Проверить целостность файлов игры»;
- Дождитесь завершения процедуры проверки. Проблема может быть решена.
Также некоторым пользователям помог тотальный выход из всех стим-файлов (друзья, магазин и другое).
Переустановка игры для исправления проблемы
Радикальным, но довольно эффективным, способом устранить ошибку «Only one instance of the game» является переустановка игры. Деинсталлируйте предыдущую версию игры, и установите самую свежую альтернативу.
Это может пригодится: Этот сеанс игры теперь недоступен в CS:GO.
Видео-инструкция
В данной видеоинструкции разобран процесс борьбы с ошибкой «Only one instance of the game can be running at one time» с помощью исправления функции предотвращения данных в ОС Виндовс. Инструкция на английском языке.
Looks like I was able to find a solution — but it looks over-complicated, so let me leave this issue open.
I have a target that generate c# sources from other file, to be a little bit more concrete, let’s say we run XSD tool. C# source are not committed in repository, as they should be auto-generated in that case.
So, it looks something like:
<ItemGroup> <None Include="Sample.xsd" /> <Compile Remove="Sample.cs" /> <!--If it was included already, remove it to avoid duplicate --> <Compile Include="Sample.cs" /> <!--Include it always, even if files don't exist --> <DependentUpon>Sample.xsd</DependentUpon> </Compile> </ItemGroup> <!--It could be optional BeforeTargets="CompileDesignTime;BeforeBuild", to allow VS generate it on first project openning--> <Target Name="GenerateXsd" BeforeTargets="BeforeBuild" Inputs="Sample.xsd" Outputs="Sample.cs"> <PropertyGroup> <GenerateXsd_Command>"$(SDK40ToolsPath)xsd.exe" "Sample.xsd" /nologo /c </GenerateXsd_Command> </PropertyGroup> <Exec Command="$(GenerateXsd_Command)" ConsoleToMSBuild="true" /> </Target>
It works great, until we enable multi-targeting with something like:
<TargetFrameworks>net40;netstandard2.0</TargetFrameworks>
Now BeforeTargets will be executed twice — for net40 build and netstandard2.0 build. It is problem, as now we have race condition when two xsd tries to generate same file and one of it could not access it, because other locks it.
My naive attempt to solve it was changing it to BeforeTargets="DispatchToInnerBuilds". It works great, while we have only one project, but if we try to build solution, which contains project, referencing us, our build could be executed from ResolveReference target of other project, which will start inner-loop build for our project — DispatchToInnerBuilds will be executed in parallel in this case, so we run compilation now before we was able to generate source.
Final working solution looks next:
<!--It could be optional BeforeTargets="CompileDesignTime", to allow VS generate it on first project openning--> <Target Name="GenerateXsdInner" Inputs="Sample.xsd" Outputs="Sample.cs"> <PropertyGroup> <GenerateXsd_Command>"$(SDK40ToolsPath)xsd.exe" "Sample.xsd" /nologo /c</GenerateXsd_Command> </PropertyGroup> <Exec Command="$(GenerateXsd_Command)" ConsoleToMSBuild="true" /> </Target> <Target Name="GenerateXsd" BeforeTargets="DispatchToInnerBuilds;BeforeBuild"> <!--TargetFramework=once is critical here, as it allow will not execute task from same project with same properties twice. We need to unify TargetFramework between empty, net40 and netstandard2.0--> <MSBuild Projects="$(MSBuildProjectFile)" Targets="GenerateXsdInner" Properties="TargetFramework=once" /> </Target>
I’m interested, if I missed some way to make it simpler?
In CLion, header only library: file «does not belong to any project target, code insight features might not work properly»
I have a header-only library project set up with the cmake command:
and I also added
but when I open a source file, I get the warning:
This file does not belong to any project target, code insight features might not work properly
and I lose a lot of the functionality on things like code completion.
What is the proper way to set this up so CLion provides its usual functionality on a header-only library?
4 Answers 4
Little background
I was having the same problem, albeit the project was not header-only, nevertheless, the open files from inc folder were throwing the aforementioned warning, even though the CMake file clearly marked that folder to be include_directory .
*.hpp files do not belong to $
Since this is a perfectly valid CMake file and adding the include files to source files is not idiomatic, I did not want to amend the CMake file.
The solution
As described on the official JetBrains Forum, the CMake file is indeed valid and the warning is shown because of the inability of CLion to properly index header files. The suggested workaround extracted from the link is to right-click the folder and Mark directory as | Library Files / Project Sources and Headers .
So, this header isn’t includes in executables and CLion notifies you that some code insight features might not work properly. As workaround you can use «Mark directory as» Library Files/Project Source and Headers for folder.
В CLion библиотека только для заголовков: файл «не принадлежит ни одной цели проекта, функции анализа кода могут работать некорректно»
У меня есть проект библиотеки только для заголовков, настроенный с помощью команды cmake:
и я также добавил
но когда я открываю исходный файл, я получаю предупреждение:
This file does not belong to any project target, code insight features might not work properly
и я теряю большую часть функциональности в таких вещах, как автозавершение кода.
Как правильно настроить это, чтобы CLion предоставлял свои обычные функции в библиотеке только для заголовков?
Маленький фон
У меня была такая же проблема, хотя проект был не только для заголовка, тем не менее, открытые файлы из inc папки выдавали вышеупомянутое предупреждение, хотя в файле CMake явно отмечена эта папка include_directory .
Файлы * .hpp не принадлежат $
Поскольку это совершенно допустимый файл CMake и добавление включаемых файлов в исходные файлы не является идиоматическим, я не хотел вносить изменения в файл CMake.
Решение
Как описано на официальном форуме JetBrains , файл CMake действительно действителен, и отображается предупреждение из-за неспособности CLion правильно индексировать файлы заголовков. Предлагаемый обходной путь, извлеченный из ссылки, — щелкнуть папку правой кнопкой мыши и Mark directory as | Library Files / Project Sources and Headers .
So, this header isn’t includes in executables and CLion notifies you that some code insight features might not work properly. As workaround you can use «Mark directory as» Library Files/Project Source and Headers for folder.
CLion code insight don’t work inside ./test folder #3581
CLion doesn’t think that .cpp files inside the ./test folder are part of the project, noting «This file does not belong to any project target, code insight features might not work properly».
Steps to Reproduce
- git clone https://github.com/platformio/platformio-examples
- Open platformio-examples/unit-testing/wiring-blink in CLion and allow it to create CMakeLists.txt and wait for the automatically started pio init command to finish
- Open ./test/test_main.cpp and note the error highlighting on all #include s
Actual Results
Using #include leads to import errors (only in CLion, project compiles and tests fine with pio CLI tool).
Expected Results
Syntax highlighting works as expected without having red underscores on all #include s and most function calls.
Additional info
System information ( uname -a ): Linux pop-os 5.4.0-7634-generic #38
9a1ea2e-Ubuntu SMP Fri Jun 19 22:43:37 UTC x86_64 x86_64 x86_64 GNU/Linux
CLion version: CLion 2020.2 EAP, Build #CL-202.6109.21
PlatformIO CLion plugin version: 202.6109.21
The text was updated successfully, but these errors were encountered:
Evelios commented Jun 23, 2021
I’m having the same issue. One way that partially gets around the problem is to mark the test directory as sources root
dumarjo commented Jun 23, 2021
I created a new file CMakeListUser.txt with this content
and now Clion is happy.
j4m3s commented Jun 3, 2022
There’s a bug open on the jetbrains site for the same thing (has been there for some years now — https://youtrack.jetbrains.com/issue/CPP-21173/Integration-of-tests-in-plugin-PlatformIO-for-CLion) . Would the bug be fixed via here in the PlatformIO core repo or on the jetbrains side? We should close one or other bug report, and given how simple the fix seems to be I’m happy to have a play around and try to create a PR if someone can point me in the right direction?
j4m3s commented Jun 3, 2022
Thank you for the pointer in the forum on where to look to create a PR to fix this @ivankravets. Having gone to do it I’ve found that you actually fixed it in commit ed33652 which went into release 5.2.1!