I have tried numerous resources and I haven't really seen a proper command or way to build the icu data dll in windows.
So I have tried -
msbuild source\allinone\allinone.sln /p:Configuration=Release /p:Platform=x64
It builds the icudt62.dll but it had reduced data set.
I tried pkgdata with dll mode and runConfigureICU with --with-data-packaging=library and none of them seem to want to work properly in building the icudt.dll file (as in the command fails miserably with lot of errors).
I tried building from Visual studio and also in command line like this -
msbuild source\allinone\allinone.sln /p:Configuration=Release /p:Platform=x64 /t:MakeData
These two work and it builds the icudata dll fully but I am not sure this is the right approach since it seems to build tests also.
Has someone tried building/packaging the entire icu data (mainly dates and timezone mappings) from windows in command line? How do we build the icu data into a dll?
TIA.
Related
I'm trying to use the msbuild to build visual studio project using command line.
I used this commands
SET VCTargetsPath=C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120
msbuild.exe ../../../embedded/ports/visualC12/config-from-host.vcxproj
/p:Configuration=Release /p:Platform=Win32 /t:rebuild
Using IDE : it took around 2 min
Using cmdline: it took around 20 min
In command line it looks like it build a lot of projects that are not built in the IDE
Any suggestions?
In command line it looks like it build a lot of projects that are not built in the IDE Any suggestions?
That because you are using the property /t:rebuild in your command.
This switch performs the same function as the Rebuild Solution menu command within the integrated development environment (IDE)-will clean and then build the solution from scratch, ignoring anything it's done before. So MSBuild will build all projects regardless of whether them were built before or not.
When you build projects in IDE with build option ranther than Rebuild, it will perform an incremental build: if it doesn't think it needs to rebuild a project, it won't. It may also use partially-built bits of the project if they haven't changed. That is the reason for a lot of projects build in command line but are not built in the IDE.
To make the build faster, you can change the property to /t:build in command line or select rebuild option when you build in IDE.
Besides, there are many factors that affect the speed of building, for example, parallel. When we build multiple projects in IDE, the default value of parallel is 8, Tools->options->Projects and Solutions->Build and Run:
MSBuild command line is also support parallel, /maxcpucount Switch
msbuild.exe myproj.proj /maxcpucount:3
So when you compare the build speed between the command line and the IDE, you have to make sure that all the relevant settings are the same for command line and IDE.
Hope this helps.
I'm trying to build V8 as part of ArangoDB using the official build scripts and following the official Windows build instructions.
The compilation fails for all v8* targets (v8-build.bat):
msbuild All.sln /t:v8 /p:Configuration=Release /p:Platform=x64
msbuild All.sln /t:v8_libbase /p:Configuration=Release /p:Platform=x64
msbuild All.sln /t:v8_libplatform /p:Configuration=Release /p:Platform=x64
error MSB4057: The target "v8" does not exist in the project.
If I open the solution file in Visual Studio, it looks like this:
I can build v8, v8_libbase and v8_libplatform just fine in VS.
Windows 7 64bit
Visual Studio 2013 Ultimate
Cygwin 2.2.0
cmake 3.3.1
You can run
set MSBuildEmitSolution=1
msbuild All.sln /t:v8
Then search in the generated All.sln.metaproj file the exact target names (<Target Name="">) of all projects you want to build. v8 can have a name like _tools_\_gyp_\v8. After that you can build projects
msbuild All.sln /t:"_tools_\_gyp_\v8" /p:Configuration=Release /p:Platform=x64
The correct way to specify a target/project if it's in a solution folder is:
msbuild all.sln /t:PATH\TO\PROJECT
But in case of (tools) and (gyp) it's simply not possible, because msbuild can't handle parentheses in the target parameter /t.
So either remove ( ) and specify the path like tools\gyp\v8, or get rid of the solution folders entirely. If the solution is flat, /t:v8 will work.
Unfortunately, both the wrapping of folder names with brackets as well as the generation of non-flat .sln are hardcoded in gyp, which generated my all.sln. There is no switch to control whether solution folders are created or not. It will create them if the target version of Visual Studio is known to support this kind of nesting.
Workaround: Force flat solution generation in gyp, see
https://github.com/arangodb/arangodb/commit/796d2d263db6271142d954c8c99b9dec0fbe75e9
Reported errors to Microsoft/msbuild and Google/gyp:
https://github.com/Microsoft/msbuild/issues/157
https://code.google.com/p/gyp/issues/detail?id=494
#dothebart and this post helped me a lot to figure it out, thank you!
In VS2013 use
msbuild All.sln /p:Project=v8;Configuration=Release;Platform=x64
I'm trying to take a couple of projects normally compiled on Windows with Microsoft C++ and compile them with clang instead.
On the upside, there exists clang-cl.exe which is designed to be a drop-in replacement for cl.exe. However, even when I copy clang-cl.exe into the current directory as cl.exe, msbuild still in some cases calls Microsoft's cl.exe.
Is there a way to tell msbuild 'here, when executing Task CL, use this cl.exe instead of the usual one'? msbuild's command line options don't contain anything obvious in that direction.
Also, is there a way to tell it to supply or override command line parameters for cl without changing the project file?
This is easy to do from either command line or project file. The properties you need to configure are $(CLToolExe) and $(CLToolPath).
From the command line:
msbuild MyProj.vcxproj /p:CLToolExe=clang-cl.exe /p:CLToolPath=c:\whatever\path\to\the\tool
Alternatively, inside your .vcxproj file:
<PropertyGroup>
<CLToolExe>clang-cl.exe</CLToolExe>
<CLToolPath>c:\whatever\path\to\the\tool</CLToolPath>
</PropertyGroup>
If you are calling task CL directly inside your .vcxproj file, as opposed to just relying on common targets, just set corresponding parameters ToolExe and ToolPath of the CL task.
Since Visual Studio 2019 16.2, Microsoft provide an integration of MSbuild and ClangCl. So this can be achieved by:
Installing the “C++ Clang Tools for Windows” component
Choosing the "LLVM (clang-cl)” toolset in the IDE
Microsoft's blog post has more information on this: https://devblogs.microsoft.com/cppblog/clang-llvm-support-for-msbuild-projects/
I were using #seva solution for sometime, though in Visual studio version Version 16.10.1 it works for me only if the 'CL' prefix is omitted from the command line parameters. i.e.:
msbuild MyProj.vcxproj /p:ToolExe=clang-cl.exe /p:ToolPath=c:\whatever\path\to\the\tool
I want to build GhostScript 9.04 for Win32 and I have read the documentation to do so which details creating your own makefile project.
I was just curious about the "ghostscript.vcproj" I'm finding in the top level directory. If I convert this to VS2010, I seem to get a good build out of it.
Is there any reason not to use this "ghostscript.vcproj"? The build commandline seems to have some extra stuff in it than what is detailed in the documentation, so I was worried that it might be making some kind of specialized build. See below
nmake -f psi\msvc32.mak SBR=1 DEVSTUDIO= && nmake -f psi\msvc32.mak DEVSTUDIO= bsc
You can use the solutions supplied, they are fine and its what we use. If you would rather use nmake and the makefiles then that's fine too, the solutions simply use the makefiles so its sort of the same, just more convenient in some ways if you are using Visual Studio.
The 'extra stuff' is in there to support the visual studio source browser, basically to improve the experience when using Visual Studio, its not essential.
I'll see about updating the documentation in make.htm.
Sorry to bump a very old topic, but when attempting to compile GhostScript v.9.14.1 with Visual Studio 2015, I get these errors:
Error U1034 syntax error : separator missing lib.mak (line 51)
Error MSB3073 The command "nmake -f psi\msvc32.mak SBR=1 DEVSTUDIO= debug && nmake -f psi\msvc32.mak DEVSTUDIO= debugbsc" exited with code 2. ghostscript C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.MakeFile.Targets
Here's the code at line 51 in lib.mak:
GLLCMS2CC=$(CC_SHARED) $(GCFLAGS) $(I_)$(GLI_) $(II)$(LCMS2SRCDIR)$(D)include$(_I) $(GLF_)
Is there any way to remedy this?
Thank you.
PS: Does this project build the DLL? Could we build the DLL ourselves?
In VS 2008 and VS 2010, one can easily create a solution and modify the "Solution Configuration". We can choose what configuration each project gets built in when we trigger a build at the solution level.
Is such a facility available in the Visual Studio 6.0?
In my experience:
when a configuration is chosen (form the list available) in VS6 for a VC++ project, the dependencies (which themselves have multiple configurations defined) get built in some random order. There is no way to control the configurations of dependencies at build time.
"Batch Build" does come close to this but is not as flexible for my purpose.
I have tried various options in the VS6.
Hope I am clear.
Here is a link on the MSDEV command line.
https://msdn.microsoft.com/en-us/library/aa699274(v=vs.60).aspx
There is a way to control the building of dependencies. Specify /NORECURSE and dependencies will not be built.
I use /REBUILD with /NORECURSE to keep the dependencies from getting built.
And I build each project one at a time inside the workspace in a bat file by doing a chdir to the subdirectory and calling MSDEV just for that subproject:
msdev myproject.dsp /MAKE "myproject - Win32 Debug" /REBUILD /NORECURSE > Build.log
Then I cd to the next project directory one at a time.
On a side note, I had difficulties for several years where NMAKE would not work for my specific tasks. Turns out that the PATH environment variable inside MSDEV (Visual Studio 6.0) is different from the PATH environment variable of a command shell you would run NMAKE on.
The Path used by the MSDEV shell is the %PATH% at the time Visual Studio 6 was installed. We use this and poke the registry as needed for MSDEV to get the correct path setup when switching revisions of our software; however this doesn't help update the %PATH%. The MSDEV path can be queried with a query script. I don't have my example handy.
That is why builds in MSDEV sometimes work when builds using the command line don't, as the path to DLLs differ, and any custom build steps that run .exe will not work outside of the MSDEV environment unless the path is updated.
I have a script somewhere that reads the queries the registry to extract the MSDEV path and update PATH of a shell so that batch scripts doing nmake will work as they would inside the MSDEV shell environment. The problem with the REGISTRY QUERY is that the return arguments differ with different flavors of Windows (XP/SERVER2003/...).
One thing I just discovered is that Incredibuild works with the old VS6.0 MSDEV IDE. This is a game changer. It distributes builds. I'm evaluating it now, but it might be useful to anyone waiting for long VS6.0 builds.