I'm trying to load an opencv example into Android Studio.
When I clone the repository, one of the files is "build.gradle.in".
Android studio normally uses "build.gradle" files, without the ".in" extension. (See
build.gradle in the project vs. build.gradle in the app
"android camera calibration"
https://github.com/rpng/android-camera-calibration/blob/master/app/build.gradle
etc.
).
What is a "build.gradle.in" file?
Do I need to do something with it?
Do I need to tell Android Studio to do something with it, and if so, how?
(I tried to search for "build.gradle.in" in my favorite search engine, but I get a bunch of irrelevant documents talking about placing the file "build.gradle" "in" some folder or another).
(Disclaimer: This is only a partial answer as I cannot tell what to do with that file)
From the contents of the repository (in particular android_gradle_projects.cmake) it appears to be a template file used as input (therefore .in) to create a final build.gradle with dynamic content.
See e.g. line 35 of android_gradle_projects.cmake:
configure_file("${OpenCV_SOURCE_DIR}/samples/android/build.gradle.in" "${ANDROID_BUILD_BASE_DIR}/build.gradle" #ONLY)
In combination with e.g. line 100 of build.gradle.in:
minSdkVersion #ANDROID_MIN_SDK_VERSION#
configure_file copies a file with modifications, e.g. replacing variables in the form of #VAR#.
I didn't manage to figure out how to use the build.gradle.in file, but you can download the openCV android sdk, which will contain the same sample projects already configured for gradle.
From a previous question a new one have arisen. I want to include 2 native TFS project libraries stored in two different folders, dependant from each other in my Android Studio project (stored in another folder). If i not specify "../my_lib_path/libFile.h" instead of simply the "libFile.h" i get the error the file is not found. But i dont want to change all includes since it is a TFS project and there are lots of file contained in the libraries!
Your help is highly appreciated!
Add the given directories to those the compiler uses to search for include files. Relative paths are interpreted as relative to the current source directory. So you have to specify "../my_lib_path/libFile.h", that means you need to change all includes, otherwise it will not work.
#Andy Li-MSFT is absolutely right! Though what worked for me in a similar project now was to set a different relative CMakeLists.txt path in the app .gradle file outside the specific Android Studio Project directory:
externalNativeBuild {
cmake {
path "../../whatever_path/my_C_files/CMakeLists.txt"
}
}
After that i was able to compile my C sources flawlessly without changing the include paths of the C project!
I have an extension for LiveCode, intended for use on both Mac OS X and iOS. The package includes a .bundle item and a .lcext item. The .lcext can be used on iOS, by including it in the Copy Files pane; this works fine when the standalone is built and deployed to a device. But I've not been able to use the .bundle in the LiveCode IDE on MacOS X.
I've tried putting either the folder with the package, or just the .bundle file, into either the "Plugins" or "Extensions" folder of ~/Documents/LiveCode; neither seems to work. Does it need to be somewhere else? Do I need to do something explicit to initialise it?
In your documents folder, there is a folder LiveCode (my folder called My Revolution Enterprise). This folder contains an externals folder and an extensions folder. The extensions folder is where you put widgets for LiveCode 8. The externals folder is where you put externals. You need to make sure that you're indeed dealing with widgets and not with externals.
However, since you have a bundle and an lcext file, it seems you're dealing with externals, Put the bundle file into the externals folder inside the LiveCode folder and edit the file Externals.txt. Add a line to the latter file. The line should contain two items, separated by a comma. The first item is the name of the external and the second item is the filename of the external. The external should not show up in the externalpackages of stack "Home" after you restart LiveCode.
After automatically upgrading the project file for a .Net 4.0 web application to work with Visual Studio 2012 everything worked ok at first however when compiling I got lots of errors like this:
Description : Source File '..\..\..\..\..\File Path' could not be found
File : CSC
And when trying to build using MSBuild (passing just the project full path, with no additional parameters) in the "Developer Command Prompt for VS2012" I got basically the same errors:
"CSC : error CS2001: Source File 'x' could not be found"
All errors refer to Linked Files (aspx,cs,etc) located in other web applications projects located at a different deep in our code Branch (that's why all the '....\' at the beginning of the paths)
To me it looks like a problem with the file Length, I had the same problem a while ago when building the projects on our CI server using MSBuild, I was able to manage it by manipulating the project files before building them using a custom script without the need to move the branch around or reduce the deep of the projects, I didn't have to move anything, the important thing at the time it was that developers using Visual Studio 2010 could compile everything without problems. I learned by this that compiling/Building with MSBuild was different that with DevEnv/VS, and for example MSBuild didn't support building Setup projects and DevEnv did.
Since this is happening now with VS 2012/DevEnv 2012 , plus that VS 2012 doesn't support setup projects anymore (like msbuild), plus VS/DevEnv have the same problem with the file length, it looks like VS 2012 its finally using msbuild under the hood or are more tightly integrated, however I didn't find any article to confirm this.
Changing the branch structure/changing the deep of the projects it’s not an option right now due to several reasons (large code base, high number of projects, risk, timing, effort, etc.).
Does someone have an alternative solution or a fix for this issue in Visual Studio 2012?
Regards,
P.D.: BTW I already checked this post MSBuild error with linked files but like I said before changing the paths its not an option right now.
Try getting the Build Logs,
http://msdn.microsoft.com/en-us/library/vstudio/ms171470.aspx
it seems that csc task could not find the source file. One cause it you import the wrong file.
so you have to edit the project file via normal Text Editor.
I found a solution to this issue, when you linked the file, you relative path is recognized by msbuild and go back from there it become your path in a long path however you can change it in the project definition doing right click/unload the project/ and change the path from ../../../ to $(SolutionDir)/../.. until find the file to link, note: it's extend the character from 255 to 300 character.
Check that you have the latest version of the linked files from the other projects. Visual Studio will NOT automatically get them if they belong to another project.
Check that the linked paths are indeed correct. You can monitor what files VS.NET and MSBUILD are trying to access with the help of the SysInternals ProcMon tool (filter on process names and filter out all successes)
If you suspect that the path length is the problem (this will also be visible in the ProcMon tool), you can try to shorten them by linking to the absolute path (C:\X\Y\Z) instead of a relative path (......\Z). The location of the linked files can then remain unchanged.
My 2 cents to this problem... In my case, I had a file created in one project (i.e. ConfigModel) and I had a link to this file in another project but when I renamed the file ConfigModel in the first project to LoginModel for example, it didn't rename the link in the second project causing this error to occur.
I know that i did this question a while ago but for what is worth, The approach that we finally went for was:
Locating the files that were reported as too long.
Reduce the full path length of those files, by reducing the length of the name and/or
the length of the container folder or reducing the folder nesting
level. Therefore reducing the full path length.
Update the links of the changed files (re-linking) on the dependant projects.
This solved the problem with Visual Studio 2012 on developers workstations and on our CI/Deploy servers that used MSbuild.
For my scenario this approach was less risky,and implied less effort than moving complete projects/solutions to reduce their folder nesting level or reducing the folder names, and have to update all the references of the dependant project/solutions.
Ok, I hit this and solved it today. I found it by following a msdn tutorial (https://msdn.microsoft.com/en-us/library/ms379563%28v=vs.80%29.aspx) and here's the command that broke for me:
csc /t:library /out:MyCodeLibrary.dll simpleType.cs
Giving me the message
error CS2001: Source file 't:librabry' could not be found
Which worked after changing the original command to the following:
csc /target:library /out:MyCodeLibrary.dll simpleType.cs
I'm not sure why the short version of the /target flag causes this error, but I've not found anywhere else online noting this cause specifically so I wanted to record it here.
This problem arose for me when I reverted to an earlier version of a git repository. Apparently I didn't add the project file to the repo so when it reverted it didn't revert the project file also. What I did to clear it up was to exclude the missing .cs file from the project by clicking on the missing file in the project Explorer. It was easy to find since it was marked with a warning triangle. Then rebuild the entire solution.
Verify whether the files mentioned in the error do not exist in the corresponding folder.
If their non-existence is intentional, edit the .csproj files and remove the reference for those files.
Build again.
I inherited this issue from a project somebody else was working on, in my case was a .cs file supposed to be generated by an Entity Framework .tt template, but for some reason it wasn't, so the compiler was going all CS2001 about that. I had to update the template and manually run it, everything worked after that.
(I'm new to CMake and I am not so familiar with Visual Studio.)
I need to implement a relatively big library the solution/project files will be generated by CMake, and my problem is that I would like the organization of the files in VC GUI to reflect the directory structure on the disk.
Basically, the library is split into different parts. For instance one of them is called "common" and will implement some headers used by the library. On the disk it will be in a specific "common" directory, which may have one or more subdirectory.
src/
common/
...
portfolio/
...
asset/
contracts/
physical_assets/
...
mathutils/
...
I'd like to have the see the same thing within Visual Studio's Solution Explorer,
but I only know how to split the solution into different projects.
How can I do that?
You can do that using SOURCE_GROUP, the CMake FAQ covers that.
I don't think you can. If you use "Show All Files" you will get what you want, but only at the project level. Creating a VS project at the root may give you the possiblity of viewing all your files, but you will still need separate projects for each exe/dll/etc. you want to build. Remember that a solution in VS terms is a set of projects, not a directory tree.
Not sure if this is what you're after, but: first make sure you have "Tools->Options->Projects and Solutions->Solution Explorer Mode" set to "Show All Files". Then if you create a VS project in the root source directory (probably the same as where your CMakeLists.txt goes), VS will show all files in that directory and all it's subirectories.