So I'm attempting my first Chrome build just for fun and I've gotten all the files I want through gclient config and sync. However, there are no project files that VS can open, just a bunch of .gyp files that are useless to me.
The command 'gclient runhooks --force' is supposed to generate the sln files for me, but when I run it I get nothing. Not even an error.
What's up?
Thanks.
Yes, this info still seems to be missing from the Chromium documentation at the moment. The way to generate your Visual Studio Solution files is:
export GYP_GENERATORS=msvs-ninja
gclient runhooks --force
You won't need the --force if it's your first time calling gclient runhooks. The generator should be good for your ninja build and it should generate your .sln files.
Yes, really annoying problem... I did all kinds of stuff to make it work, and this is how I made it work in the end, believe it or not:
Restart PC
In terminal cd to the dir containing .gclient file
checkout Important note below if you never used GYP before
gclient runhooks --force
profit
Important: You must also set environment variable named GYP_GENERATORS to a value listing build project types. For example, to generate NINJA build files and Microsoft Visual Studio (your case) do this if in linux terminal export GYP_GENERATORS=ninja,msvs or if Windows cmd setx GYP_GENERATORS ninja,msvs /M before step 4. This way you control what project types will be generated on runhooks.
Related
I'm trying to run a piece of software I built in MSYS2 MINGW32 shell. The software is 32bits (don't have time to port it to 64bits) and there is one statically linked executable. Here is how I setup the build environment:
Installed a fresh copy of MSYS2;
$ pacman -Syu
Installed the following packages: git mingw-w64-i686-gcc mingw-w64-i686-cmake mingw-w64-i686-SDL mingw-w64-i686-SDL_mixer mingw-w64-i686-zlib mingw-w64-i686-libpng mingw-w64-i686-make
Git checkout the repo
Run the build in CMake
Build runs fine and the exe is generated.
Now the problem starts: the executable can't run and displays an error message about missing DLLs. I copied the missing DLLs to the same folder of the executable, and them another error message pops up complaining about error 0xC000007B, which I tracked down to be missing dependencies. After a while I figured out that the problem was that some of the DLLs is missing a dependency itself. Copied this last dependency to the folder.
Now, the big question: I can run the exe perfectly fine in the MINGW32 shell but I can't run it neither in cmd.exe nor by double-clicking in Windows Explorer and this is a problem (I can't ship a software this way). Is there any way to produce a binary that is able to run from explorer and from cmd.exe? What is the cause of this problem? Can it be mitigated?
I solved my problem!
After a lot of research, I realized that nothing was wrong with my MSYS2 build/setup/dependencies. The real problem was that CMake hide one parameter for the linker: -mwindows. Actually, the CMake find_package routine from one of the libraries I'm using (SDL) added this parameter to the linker command line parameters.
Adding a -mconsole to the linker parameters (using add_link_options("-mconsole")) solved the problem. The CLI now works as expected.
Thank you all for your help.
I want to investigate a new application for JPEG 2000 encoding and decoding. I downloaded openjpeg-master and managed to cobble together the ability to cmake the files. After a bunch of grinding, this resulted in the following output:
"Build files have been written to: C: openjpeg-master/build
\build> "
Any "normal" Unix installations have a multi-step installation like this:
"UNIX/LINUX - MacOS (terminal) - WINDOWS (cygwin, MinGW)
To build the library, type from source tree directory:
mkdir build
cd build
cmake .. -DCMAKE_BUILD_TYPE=Release
make
Binaries are then located in the 'bin' directory.
To install the library, type with root privileges:
make install
make clean
To build the html documentation, you need doxygen to be installed on your system. It will create an "html" directory in TOP_LEVEL/build/doc)
make doc"
But the Windows 10 equivalent is unclear, to put the most charitable spin on it. You can find it here: "https://github.com/uclouvain/openjpeg/blob/master/INSTALL.md"
Some questions arise:
is there a better starting place for installing JPEG 2000 that actually shows me how to install it and run the tests?
if not, how do I get from the build files to installing the libraries and making the test programs?
Is there more information I can dig out that would help to answer these questions?
Since I'm allergic to Visual Studio, I overlooked a nice tutorial specifying how to install something as complex as openjpeg by direct clone from github. However, in desperation, I found it and it worked. It is Visual Studio Community 2019 Version 16.8.3. I needed only to use -DTHIRDPARTY to get the third party libraries installed. There is a drop-down menu to build and install OPENJPEG. All I need to do now is figure out how to compile and run the utilities that invoke the installed libraries ...
actually, the complete line to add was -DBUILD_THIRDPARTY:bool=true.
Somewhere in my frantic random search for a way forward, I remember seeing the thought that to make the tests work, I merely need to find files like *.vsproj and run them a separate VS solutions. Some random guesswwork with .vdproj files in src/bin/... hasn't produced anything good. Is there not a document somewhere showing how to run the tests?
I've downloaded the source files for the TBB libraries, with the intent to build them and link them into my CMake project. The readme file says "type 'gmake' in this directory to build and test."
My question is - how do I run gmake on a Windows machine.
The solution in this answer didn't work for me. This is what I get:
From the log I see that make unable to find Microsoft compiler cl.exe. To fix this, you must use one of the "Visual Studio command prompt"-s, those are cmd with environments targeted to command-line tools.
If you use MigGW by chance, the command should be
make compiler=gcc.
In this case, path environment variable should contain path to MigGW.
I installed the TSC with NPM yesterday and when I download the last Typescript definitions from the repository with tsd#0.5.7 and I proceed to compile my code I got a lot of compile errors from the definitions. The only way that I have found to fix this kind of errors is going back to definitions for the typescript 1.3, Do you have an idea why this is happening?
Update 1
I installed the tsc for my mac (the installation mentioned before was in Windows) and when I run tsc --version I got different results, even if both of they say they are 1.4.1
Windows:
Mac
Probably your PATH environment variable is wrong, you can check that by executing echo %PATH% and you will probably see something like C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0\; there before the roaming npm path.
You can change that by going to the Control Panel -> System & Security -> and on the left there is "Advanced System settings", click on It and a popup will open. Chose the tab "advanced" there and click the button "Environment variables", there you can change your path.
Reopen your command prompt (MSys on the look of your screenshot) or the change wont have any effect.
I hope the names are right, because I'm currently on a Dutch Windows version. If you have any problems please let me know :)
I rename the path of the 1.0 version to 1.0.1 and when I type tsc -v the result was 1.4.0.0
I changed from :
C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0
To:
C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0.1
And it worked.
I installed the TSC with NPM yesterday and when I download the last Typescript definitions from the repository with tsd#0.5.7 and I proceed to compile my code I got a lot of compile errors from the definitions
Not possible if tsc is pointing to typescript#1.4.1. Run where tsc (windows) or which tsc (unix) or tsc --version. If it ain't the right version, then you have your answer. The following shows one error scenario:
I'm attempting to do a command line package deploy for our Windows Store Application.
My command line instructions are:
msbuild /m /p:Configuration=Debug /p:Platform=x86 /target:Build
I'm using VS2013 Professional with Windows 8.1
I get the following error:
C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v12.0\AppxPackage\Microsoft.AppXPackage.Targets(1224,9):
error APPX0002: Task 'GenerateAppxPackageRecipe' failed. Value cannot
be null.\r [C:\Path\Project.csproj]
C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v12.0\AppxPackage\Microsoft.AppXPackage.Targets(1224,9):
error APPX0002: Parameter name: source\r [C:\Path\Project.csproj]
How should I resolve this?
This error was resolved by using the correct version of msbuild.exe
On a clean build server with VS2013 installed, there are (at least) two copies of msbuild.exe installed. In our case the install locations were:
C:\Program Files (x86)\MSBuild\12.0\Bin\msbuild.exe
and
C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe
The one in the .Net Framework folder was the one that gave us the errors. Using the version installed in the Program Files folder resolved the issue.
It's impossible to help you without having the code which can reproduce the error. I suspect some property does not resolve correctly when building outside VS(eg VisualStudioVersion) and needs to be passed from command line. VS also uses msbuild to build your projects, so comparing build logs from VS and CMD should help you track down the problem.
I suggest, that you set visual studio's build output verbosity to diagnostic, clean solution, than build and capture the build log.
Then clean solution and build from command line with verbosity set to diagnostic and /fl switch(log to file, because diagnostic build log is way too long to analyse in console window).
Compare command-line output to VS output. Look for the differences. With diagnostic level of verbosity, chances are, you'll find out what's missing (I had similar issues with database projects failing to build from cmd due to VisualStudioVersion variable not being resolved correctly, so I passed it from command line).
NB: diagnostic log is very verbose which makes analysis hard: I'd start from detailed verbosity level.
I have deleted all files/folders from "project"/bin folder, cleaned the solution and rebuild with success !
For those facing the issue on hybrid app (corodova in my case), delete the build folder manually and re-build from VS.
Standard clean solution didn't do the job.