What's the advantage of saying
#pragma comment(linker, "/manifestdependency:\"type='win32'" \
"name='Microsoft.Windows.Common-Controls'" \
"version='6.0.0.0'" \
"processorArchitecture='x86'" \
"publicKeyToken='6595b64144ccf1df' language='*'\"")
instead of
#pragma comment(linker, "/manifestdependency:\"type='win32'" \
"name='Microsoft.Windows.Common-Controls'" \
"version='6.0.0.0'" \
"processorArchitecture='*'" \
"publicKeyToken='6595b64144ccf1df' language='*'\"")
when specifing a manifest?
Using x86 means that the manifest cannot be used if you target 64 bit platforms. I'd say that this was a disadvantage. I think using * is better.
Related
I am using Picard to mark only optical duplicates for which I read the manual of MarkDuplicates. My script looks like this
#!/usr/bin/bash
java -jar build/libs/picard.jar MarkDuplicates \
I=sorted.bam \
O=mark_opticalduplicate.bam \
MAX_OPTICAL_DUPLICATE_SET_SIZE=300000 \
TAGGING_POLICY=OpticalOnly \
M=markedoptical_dup_metrics.txt
I am not sure I am getting only optical duplicates when I am using the samtool flag 0x400
Any suggestions at this point is highly appreciated.
I am trying to build glpk to use in VS2019 but I got a problem that I cannot solve.
In the file Build_GLPK_with_VC9.bat I changed the directory to the folder which contains the file vcvars64.bat but when I compile I get the following error message:
[vcvarsall.bat] Environment initialized for: 'x64'
The system cannot find the path specified.
The system cannot find the path specified.
Somebody has an idea of how to solve this? I am executing the .bat while while admin mode but the error message persists.
EDIT
This is the original .bat file provided by glpk:
rem Build GLPK with Microsoft Visual Studio Express 2008 and
rem Windows Software Development Kit (SDK) for Windows Server 2008
rem NOTE: Make sure that HOME variable specifies correct path.
set HOME="C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC"
call %HOME%\bin\vcvars64.bat
copy config_VC9 config.h
%HOME%\bin\nmake.exe /f Makefile_VC9 all
%HOME%\bin\nmake.exe /f Makefile_VC9 check
pause
And this is the same file with the path required:
rem Build GLPK with Microsoft Visual Studio Express 2008 and
rem Windows Software Development Kit (SDK) for Windows Server 2008
rem NOTE: Make sure that HOME variable specifies correct path.
set HOME="C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC"
call %HOME%\Auxiliary\Build\vcvars64.bat
copy config_VC9 config.h
%HOME%\bin\nmake.exe /f Makefile_VC9 all
%HOME%\bin\nmake.exe /f Makefile_VC9 check
pause
The file Makefile_CV9 contains
# Build GLPK with Microsoft Visual Studio Express 2008 and
# Windows Software Development Kit (SDK) for Windows Server 2008
CFLAGS = /I. /DHAVE_CONFIG_H /nologo /W3 /MT /O2
OBJSET = \
..\src\glpapi01.obj \
..\src\glpapi02.obj \
..\src\glpapi03.obj \
..\src\glpapi04.obj \
..\src\glpapi05.obj \
..\src\glpapi06.obj \
..\src\glpapi07.obj \
..\src\glpapi08.obj \
..\src\glpapi09.obj \
..\src\glpapi10.obj \
..\src\glpapi11.obj \
..\src\glpapi12.obj \
..\src\glpapi13.obj \
..\src\glpapi14.obj \
..\src\glpapi15.obj \
..\src\glpapi16.obj \
..\src\glpapi17.obj \
..\src\glpapi18.obj \
..\src\glpapi19.obj \
..\src\glpavl.obj \
..\src\glpbfd.obj \
..\src\glpbfx.obj \
..\src\glpcpx.obj \
..\src\glpdmp.obj \
..\src\glpdmx.obj \
..\src\glpfhv.obj \
..\src\glpgmp.obj \
..\src\glphbm.obj \
..\src\glpini01.obj \
..\src\glpini02.obj \
..\src\glpios01.obj \
..\src\glpios02.obj \
..\src\glpios03.obj \
..\src\glpios04.obj \
..\src\glpios05.obj \
..\src\glpios06.obj \
..\src\glpios07.obj \
..\src\glpios08.obj \
..\src\glpios09.obj \
..\src\glpipm.obj \
..\src\glpipp01.obj \
..\src\glpipp02.obj \
..\src\glplib01.obj \
..\src\glplib02.obj \
..\src\glplib03.obj \
..\src\glplib04.obj \
..\src\glplib05.obj \
..\src\glplib06.obj \
..\src\glplib07.obj \
..\src\glplib08.obj \
..\src\glplib09.obj \
..\src\glplib10.obj \
..\src\glplib11.obj \
..\src\glplib12.obj \
..\src\glplpf.obj \
..\src\glplpp01.obj \
..\src\glplpp02.obj \
..\src\glplpx01.obj \
..\src\glplpx02.obj \
..\src\glplpx03.obj \
..\src\glplpx04.obj \
..\src\glplpx05.obj \
..\src\glplpx06.obj \
..\src\glplpx07.obj \
..\src\glplpx08.obj \
..\src\glplpx09.obj \
..\src\glpluf.obj \
..\src\glplux.obj \
..\src\glpmat.obj \
..\src\glpmpl01.obj \
..\src\glpmpl02.obj \
..\src\glpmpl03.obj \
..\src\glpmpl04.obj \
..\src\glpmpl05.obj \
..\src\glpmpl06.obj \
..\src\glpmps01.obj \
..\src\glpmps02.obj \
..\src\glpnet01.obj \
..\src\glpnet02.obj \
..\src\glpnet03.obj \
..\src\glpnet04.obj \
..\src\glpnet05.obj \
..\src\glppds.obj \
..\src\glpqmd.obj \
..\src\glprgr.obj \
..\src\glprng01.obj \
..\src\glprng02.obj \
..\src\glpscf.obj \
..\src\glpscg.obj \
..\src\glpscl.obj \
..\src\glpspm.obj \
..\src\glpspx01.obj \
..\src\glpspx02.obj \
..\src\glpsql.obj \
..\src\glpssx01.obj \
..\src\glpssx02.obj \
..\src\glptsp.obj
.c.obj:
cl.exe $(CFLAGS) /I..\include /Fo$*.obj /c $*.c
all: glpk.lib glpsol.exe
glpk.lib: $(OBJSET)
lib.exe /out:glpk.lib ..\src\*.obj
glpsol.exe: ..\examples\glpsol.obj glpk.lib
cl.exe $(CFLAGS) /Feglpsol.exe ..\examples\glpsol.obj glpk.lib
check: glpsol.exe
.\glpsol.exe --mps ..\examples\plan.mps
You just have to find the exact paths for "vcvars64.bat" and "nmake.exe".
I had the same problem, and this is what worked for me:
rem Build GLPK with Microsoft Visual Studio Express 2008 and
rem Windows Software Development Kit (SDK) for Windows Server 2008
rem NOTE: Make sure that HOME variable specifies correct path.
set HOME="c:\Program Files (x86)\Microsoft Visual Studio"
call %HOME%\2019\Community\VC\Auxiliary\Build\vcvars64.bat
copy config_VC9 config.h
%HOME%\2019\Community\VC\Tools\MSVC\14.28.29333\bin\Hostx64\x64\nmake.exe /f Makefile_VC9 all
%HOME%\2019\Community\VC\Tools\MSVC\14.28.29333\bin\Hostx64\x64\nmake.exe /f Makefile_VC9 check
pause
I'm running into an odd behavior on the latest version of vagrant in a Windows7/msys/Virtualbox environment setup, where after executing a vagrant up command I get an error with rsync; 'file has vanished: "/c/Users/spencerd/workspace/watcher/.LISTEN' doing the provisioning stage.
Since google, irc, and issue trackers have little to no documentation on this issue I wonder if anyone else ran into this and what would the fix be?
And for the record I have successfully build a box using the same vagrant file and provisioning script. For those that want to look, the project code is up at https://gist.github.com/denzuko/a6b7cce2eae636b0512d, with the debug log at gist.github.com/
After digging further into the directory structure and running into issues with git pushing code up I was able to find a non-existant file that needed to be removed after a reboot.
Thus, doing a reboot and a rm -rf -- "./.LISTEN\ \ \ \ \ 0\ \ \ \ \ \ 100\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ " did the trick.
Is there any way to tell Visual Studio 2010 (or Visual Studio 11 Developer Preview) to use a sources file?
Is there any tools for converting from nmake/dirs/sources to MSBuild?
I really want to use the Visual Studio 11 Developer Preview Code Analysis tools on a very old C++ solution, which currently doesn't even come close to being able to compile in Visual Studio.
Here's an example of one of the many sources files:
!INCLUDE $(INETROOT)\build\paths.all
!INCLUDE $(INETROOT)\build\sources.all
TARGETNAME=CSDWCtlg
TARGETTYPE=DYNLINK
DLLENTRY=DllMainCRTStartupCustom
DLLDEF=
USE_NATIVE_EH=1
NO_NTDLL=1
NTTARGETFILE0=$(EXPORTED_FILES)
INCLUDES= \
$(INCLUDES); \
$(SDK_INC_PATH); \
$(ATL_INC_PATH); \
$(CSSTORAGE)\inc; \
$(CSSTORAGE)\util\inc; \
$(CSSTORAGE)\dbg; \
$(CSSTORAGE)\msg; \
$(CSSTORAGE)\intf\idl; \
$(CSSTORAGE)\ctlg; \
$(CSSTORAGE)\provider; \
$(CSSTORAGE)\dsproviders\inc\; \
$(CSCOMMON)\rockall4\Build\Rockall\Include; \
$(CSCOMMON)\rockall4\Code\Rockall\Interface; \
$(CSCOMMON)\kbase; \
$(CSCOMMON)\inc; \
# goes to both RC compiler and C compiler
# RUN_WPP=$(SOURCES) -func:{LEVEL=Error}ErrorTrace(ERR,MSG,...) -func:{LEVEL=Debug}DebugTrace(DBG,MSG,...)
C_DEFINES=$(C_DEFINES) /D_UNICODE /DUNICODE /DPROJ_METABASE /DCSTRACE_CSDWCTLG /D_CTLG_DIAGNOSTIC#1
USER_C_FLAGS=$(USER_C_FLAGS) -D_CTLG_DIAGNOSTIC=1 -GR -D_WIN32_WINNT=0x0500 -DOLEDBVER=0x0250
# check for 64-bit compatiblitly
!if "$(PROCESSOR_ARCHITECTURE)"=="x86"
USER_C_FLAGS = $(USER_C_FLAGS) /Wp64
!endif
# The line below includes the common build flags.
# It modifies the USER_C_FLAGS variable by appending the 'project' level flags.
# Be sure to use the syntax USER_C_FLAGS=$(USER_C_FLAGS) 'flags' if you use USER_C_FLAGS after this include.
!INCLUDE $(CSSTORAGE)\inc\userFlags$(DCRT).inc
USE_MSVCRT=1
PRECOMPILED_CXX=1
PRECOMPILED_INCLUDE=pch.hpp
PRECOMPILED_PCH=pch_hpp.pch
PRECOMPILED_OBJ=pch_hpp.obj
SOURCES=\
csdwctlg.rc \
pch.cpp \
dll.cpp \
crow.cpp \
ctlgdump.cpp \
ctlghandler.cpp \
ctlgobj.cpp \
ctlgobjaccess.cpp \
ctlgobjclsdef.cpp \
ctlgobjdefs.cpp \
ctlgobjget.cpp \
ctlgobjkeydef.cpp \
ctlgobjmemdef.cpp \
ctlgobjrel.cpp \
ctlgobjrow.cpp \
ctlgobjset.cpp \
ctlgobjtbl.cpp \
ctlgobjtbls.cpp \
ctlgobjtypedef.cpp \
ctlgobjview.cpp \
ctlgpersist.cpp \
ctlgresolve.cpp \
ctlgresolve2.cpp \
ctlgpartresolve.cpp \
ctlgaggrresolve.cpp \
ctlgfilterresolve.cpp \
ctlgvalidate.cpp \
expschema.cpp \
mbcatalog.cpp \
mbictlgchg.cpp \
schemamgr.cpp \
sqlpathtrans.cpp \
TARGETLIBS= \
$(DEFAULTLIBS) \
$(SDK_LIB_PATH)\ole32.lib \
$(SDK_LIB_PATH)\oleaut32.lib \
$(SDK_LIB_PATH)\uuid.lib \
$(SDK_LIB_PATH)\urlmon.lib \
$(TARGETPATH)\*\CSDWIntf.lib \
$(TARGETPATH)\*\CSDWUtil.lib \
$(SDK_LIB_PATH)\msi.lib \
$(TARGETPATH)\*\csrockall.lib \
$(TARGETPATH)\*\CSDWSrvrDLL.lib \
$(SDK_LIB_PATH)\Kernel32.lib \
$(SDK_LIB_PATH)\user32.lib \
$(SDK_LIB_PATH)\Advapi32.lib \
$(CRT_LIB_PATH)\oldnames.lib \
$(SDK_LIB_PATH)\atls$(DCRT).lib \
# For Binplacing
MISCFILES= \
.\SCHEMA\* \
Any advice?
UPDATE: I've found nmake2msbuild.exe which is part of the WDK. It is intended for driver development and converts dirs and sources to MSBuild projects. I am not sure if it's going to work for what I have to do (not drivers), but I'm going to give it a try.
I've found nmake2msbuild.exe which is part of the WDK. It is intended for driver development and converts dirs and sources to MSBuild projects.
Some manual tweaking of the sources files was required to get the tool to complete conversion. It doesn't do everything, but helps get things on track.
I just finished porting the QT4.5.3 GUI lib with touchscreen lib tslib1.4.1 to arm9 based S3C2440;but I find programs are running slow.How to make Qt4.5.3 run more smoothly?
I have already read the references on http://doc.trolltech.com/4.7-snapshot/fine-tuning-features.html and http://doc.trolltech.com/4.7-snapshot/qt-performance.html Any other suggestion according to your experience?Thanks！
I use the S3C24xx too. I use Qt 4.6.2. Here is my compile configuration
#host:/qt-everywhere-opensource-src-4.6.2#./configure \
-opensource \
-confirm-license \
-release -shared \
-embedded arm \
-xplatform qws/linux-arm-g++ \
-depths 16,18,24 \
-fast \
-optimized-qmake \
-pch \
-qt-sql-sqlite \
-qt-libjpeg \
-qt-zlib \
-qt-libpng \
-qt-freetype \
-little-endian -host-little-endian \
-no-qt3support \
-no-libtiff -no-libmng \
-no-opengl \
-no-mmx -no-sse -no-sse2 \
-no-3dnow \
-no-openssl \
-no-webkit \
-no-qvfb \
-no-phonon \
-no-nis \
-no-opengl \
-no-cups \
-no-glib \
-no-xcursor -no-xfixes -no-xrandr -no-xrender \
-no-separate-debug-info \
-nomake examples -nomake tools -nomake docs \
-qt-mouse-tslib -I/usr/local/tslib/include -L/usr/local/tslib/lib
#host:/qt-everywhere-opensource-src-4.6.2# make
#host:/qt-everywhere-opensource-src-4.6.2# make install
Also notice that, if you change optimization level of compiler in file qt-everywhere-opensource-src-4.6.2/mkspecs/common/g++.conf from -O2 to -O0 may cause the Qt library run very slow.
Hope it is useful for you.
I suggest running a profiling tool to see what your program is actually doing. It might be that another part of your program is hogging the CPU. Performance problems are often first noticed through the GUI since it is something that the user sees and interacts with. Oprofile is a good tool to try out.