I recently installed ComputeCpp to D:/Programs/Codeplay/ComputeCpp. Then I set ComputeCpp_DIR="D:/Programs/Codeplay/ComputeCpp" in the CMakeLists.txt file for compiling OpenCV. I use cmake-gui.exe to configure build options and to generate the project files for Visual Studio 2019.
After each time I press Configure in cmake-gui.exe, the variable ComputeCpp_DIR is reset to ComputeCpp_DIR-NOTFOUND. The value "D:/Programs/Codeplay/ComputeCpp" is correct according to the official guide at https://developer.codeplay.com/products/computecpp/ce/guides/, i.e. "This should be set to the root directory of the ComputeCpp install (i.e the directory with the folders bin, include, lib)". The specified path does not contain any white space characters either. I also tried to modify build/CMakeCache.txt directly, but cmake-gui.exe keeps resetting my setting.
I wonder why?? How can I get cmake to accept my setting, which is apparently correct.
Add an empty ComputeCppConfig.cmake file into the D:/Programs/Codeplay/ComputeCpp directory. After that cmake-gui.exe will stop overwriting your setting.
Related
I can't get rid of this build error in my .net maui app in Visual Studio for Mac 2022 v17? The build output says:
/usr/local/share/dotnet/packs/Microsoft.Maui.Resizetizer.Sdk/6.0.300-rc.3.5667/targets/Microsoft.Maui.Resizetizer.targets(511,9): error : One or more invalid file names were detected. File names must be lowercase, start and end with a letter character, and contain only alphanumeric characters or underscores:
When I copied the image files into the resource/image folder they did have invalid characters, but I renamed the files to only have valid lowercase alpha numeric letters but still visual studio is just broken. I've cleaned the project, manually deleted bin and obj folders, restarted the solution and visual studio and even booted the whole machine with no success. I've even tried to delete all images but no luck.
There must be some other cache that is still holding invalid references of the error message is simply wrong and is thrown for some other related reason. Any help finding this issues would be greatly appreciated.
Edit
I have now created a new project (MyMauiSolution) and one by one copied the folders from the old solution to see where it would break. After all files are coped into the new project it still works. So now I have 2 solutions with more or less exactly the same files/images, where one is working and the other is not?!
I have even tried diffing the folder structures, but there are no differences?!
myiMac:Projects user_x$ diff -rq BlueWhaleMaui MyMauiSolution
Files BlueWhaleMaui/.DS_Store and MyMauiSolution/.DS_Store differ
Only in BlueWhaleMaui: .git
Only in BlueWhaleMaui: .gitignore
Only in BlueWhaleMaui: BlueWhaleMaui
Only in MyMauiSolution: MyMauiApp
This is likely caused by the existence of a hidden file in the Resources\Images directory created by the Mac operating system when using the Finder to manipulate files in that directory. (.DS_store)
The .DS_store is not visible in Finder even when 'Show All Files' is turned on, so to confirm:
Open the Terminal application
Change to your project's Resources\Images directory
Perform the command 'ls -la' in the Resources\Images directory
Confirm the existence of the '.DS_store' file (or any other 'dot' file)
There are two solutions (one a workaround, really)
Simply use the Terminal application window to delete the file
Edit your project (csproj) file to exclude the .DS_store from resizing
If you delete the file using terminal the issue will return the next time you use Finder to manipulate files in that folder/directory.
Alternatively, open your project (csproj) file and find the section that defines the MauiImage resources in your project. It should look something like this :<MauiImage Include="Resources\Images\* />
Change that from a single wildcard to a list of more specific patterns to include:
<MauiImage Include="Resources\Images\*svg />
<MauiImage Include="Resources\Images\*png />
<MauiImage Include="Resources\Images\*jpg />
This should include only files ending in these image-type file extensions in the resizing process and skipping the .DS_store file.
I had the same problem. As a workaround I deleted 'Images' folder (after backed up), create a new 'Images' folder and restore the images.
I have a project (C:\Test\Test.dpr) that uses a file (External.pas) belonging to library (MyLib.DPK). All files in the library are accessible via 'Search' path but I also included External.pas directly in my DPR file:
program Test;
uses
External in '..\Packages\MyLib\External.pas', <------ the 'external' file
FormMain in 'FormMain.pas' {frmMain};
For this project I set the 'Output directory' and 'Output DCU dir' to ".\$(Platform)_$(Config)".
When I compile, the exe file all DCUs of this project are written in the correct output folder: c:\Test\Win64_Debug\
However, the External.dcu is generated in ..\Packages\MyLib\External.dcu
instead of c:\Test\Win64_Debug\
Why is that?
Let me ask the question in a different way: if to a DPR project I append a PAS file that is in a different folder, shouldn't all DCU files (including the external file) be generated in the same folder as the EXE file?
From the documentation:
Output directory
Specifies where the compiler should put the executable file.
Unit output directory
Specifies a separate directory to contain the compiled units (.dcu).
It sounds like you need to specify the unit output directory as well as the output directory. Personally I tend to keep these two directories separate.
Yes the Project Options UI can be quite confusing especially because in order to access settings for each target platform you need to switch to that target platform via the dropdown list.
This part of the IDE could be made much better if you could simply see configurations for all target platforms at once.
Now if you want to be able to maintain output paths setting on one location (All configurations) you just need to make sure that specific target configurations are not overriding it.
To do so go to specific target configuration and then instead of clicking on the field entry itself click on the + sign in front of it.
This will expand current property field and also show the values from parent configurations from which this property can be inherited from.
NOTE: While many properties can indeed be inherited (property values from target configuration are added to properties from parent scheme like) Output directory and Unit output directory since they can contain only one value are simply overridden.
So in order to make sure that output locations from All configurations is used in every specific target configurations none of them should not have defined custom value for output locations.
In other words values from Release configuration - ... or Debug configuration - ... when you have specific property expanded must be empty like in the picture above.
Damn it... I did it again... I set the Target for 'All configurations - All Platforms' but the path for 'Debug config-64bit windows platform' was already set to something else. So, when I set the (correct) path in 'All configurations', the 'Debug config-64bit windows platform' remained as it was. I have 12 possible configurations (debug, release, pre-release) so I haven't seen that 'Debug config-64bit windows platform' remained set to the original value. The GUI for Project Options can cause lots of mistakes!
Thanks David. Sorry for wasting your time. I am still struggling with Delphi paths. There is nothing in the whole IDE as confusing/weird as the paths (search, output, library, etc)
I wanted to reach my project folder's directory through the terminal so to make things a little easier, I simply moved the project folder onto my desktop, when doing this i was presented with this prompt:
I then pressed re-save and was presented with this prompt:
After this i moved the folder back in its original place, but when i attempt to build the app i get the following 30 Apple Mach-O Linker Error errors:
I attempted a clean/clean build folder... but no success. Now I have the parse and AWS SDK frameworks installed within my project, so I completely removed them both, re-inserted them, cleaned the project, build and still the same 30 errors. What seems to be the issue? I may also add i mistakenly dragged the project folder onto the desktop and out of its original folder while the app was still running. If that means anything. What can I do?
Maybe you have an absolute path somewhere in your project's or target's settings, or a relative path pointing to a dependency outside the folder you moved. You could try to look for parts of the previous path in the settings. Alternatively with text search in a terminal, you can try something like this (in this case from the project's root directory):
grep -r "mypath/mypath" myproject.xcodeproj/project.pbxproj
Also to shed a bit more light into the issue try dragging the project back to the original folder. Is the issue fixed? If yes it's definitely a path problem.
If I create a new application project, the build settings look something like this:
It claims to be using a build dir build/Debug-iphoneos. I assume this is relative to the project directory? In reality, the project is compiled to the "derived data" directory, under ~/Library/Developer/Xcode/DerivedData/CryptoTest2-abc...
So what is going on here? Is this build setting simply ignored? What is the build setting that controls the output directory?
This build setting is actually relative to the Derived Data setting.
You can change this setting if you go to Xcode > Preferences > Locations, and change the Derived Data directory setting to whatever suits your needs (Default, Relative or Custom).
You can also specify this on a per project-basis, if you specify an absolute path for that settings:
You can either hardcode a path such as /build/${CONFIGURATION}${EFFECTIVE_PLATFORM_NAME}, then the project will be built into the folder build in the root folder.
Or can you can choose to prepend the existing path with another environment variable. For example, to make the path relative to your project/workspace (As you would expect), you can prepend the original value with ${SRCROOT}/, effectively creating a build folder at the root of your project/workspace.
Settings that can be substitued in ${<setting>} are called Build settings, and are set automatically by Xcode/xcodebuild whenever you start building your project. Apple maintains a list of the available build settings here:
http://help.apple.com/xcode/mac/8.0/#/itcaec37c2a6
Go to File -> Workspace Settings -> Advanced and select Legacy
I've searched and haven't been able to find an answer but can't believe I'm the first to encounter this.
I'm accessing INFOPLIST_FILE in an XCode 4.6 run script. In one project, the value is relative to my project. In another, it's an absolute path.
I've tried selecting the info.plist file in Xcode and under the File Inspector verified they both are set relative to the project. I've also tried cleaning the project but the results are the same.
I've verified they are different by using printenv > ~/Desktop/printenv.txt in the script.
It's an issue because I'd like to have the same script file for all my projects and this really messes up accessing the plist.
I appreciate any light you shed on this
I think the INFOPLIST_FILE variable is set based on the "Info.plist File" build setting. Can you check what it is set to in the different projects? My guess is that in one of the project it is set to Project-A/Project-A-Info.plist and in the other one set to $(SRCROOT)/Project-B/Project-B-Info.plist where $(SRCROOT) is a variable Xcode provides that is the absolute path to the source root.