KDiff3 ships with a diff3_cmd.bat for use with the svn diff3-cmd. See below (comments stripped)
SET DIFF3="C:\Program Files\KDiff3\kdiff3.exe"
SHIFT
SHIFT
SET MINE=%7
SET OLDER=%8
SET YOURS=%9
%DIFF3% %OLDER% %MINE% %YOURS% -o merged.txt
type merged.txt
del merged.txt
According to the docs I should be able to pass --auto to hide the GUI.
--auto No GUI if all conflicts are auto-solvable. (Needs -o file)
However, it still pops up a dialog saying
Total number of conflicts: 6
Nr of automatically solved conflicts: 6
Nr of unsolved conflicts: 0
I tried adding --cs "ShowInfoDialogs=0", however that hides the dialog when there are unresolved conflicts too.
Is there an option to hide the GUI completely on resolved conflicts but show the GUI and normal dialogs when there are conflicts?
Alternatively, is it possible to do a dry run to determine whether there are any unresolved conflicts then use --cs "ShowInfoDialogs=0" if it can be fully resolved and --cs "ShowInfoDialogs=1" if it will need manual intervention?
Related
I use both intel and gnu fortran compilers. Syntastic gives the following errors when I compile my module, with these settings:
syntastic_fortran_compiler set to 'ifort' & using ifort -c my_mod.f90, then it displays an error on the USE my_mod line.
syntastic_fortran_compiler set to 'gfortran' & using gfortran -c my_mod.f90, then it displays an error on the CALL subroutine line.
To change the value of syntastic_fortran_compiler, I edit the file: syntastic-checkers.txt by accessing it through :help syntastic-checkers-fortran in vim.
There is no problem with the code running though; everything is fine. The module does what it is supposed to. I like the loc_list when it displays errors, but it is irritating when it comes up with a non-removable, non-error. For now, I have set let g:syntastic_auto_loc_list = 0.
This is produced on a machine with gcc version 4.8.4. An interesting thing is that when I do this on a machine with gcc version 5.*, the gfortran error disappears. Also, I use ifort version 16.0.3 .
EDIT1: I see the errors when I open the main program file with vim after I compile as above.
EDIT2: As lcd047 mentions in the comments, I am supposed to add let g:syntastic_fortran_compiler ="ifort" to my .vimrc. Doing so resolves error(1), and now both cases produce error(2).
EDIT3:
The funniest thing happened. After I performed EDIT2, I indented the code inside the SUBROUTINE contained in my MODULE, because the cursor kept jumping one indent every time I pressed enter, and it was getting irritating (up until now all code in the module was without indentation).
Then, when I opened my main file this time, syntastic actually tells me what is wrong as an error message (till now it only said error). Message: The type of the actual argument differs from the type of the dummy argument. It underlined all the REALs amongst the args (I have REAL and INTEGER args).
So then I open my_mod.f90 to check; everything seems okay. And this time when I open main.f90, there isn't an error anymore. What I wrote above is all I did. I have no idea how the error disappeared.
EDIT4: The above effect is reproducible. When g:syntastic_fortran_compiler = "ifort", if I compile once with gfortran, and open the file, syntastic says that it does not recognize the module. That is okay. Now, if I compile again with ifort, syntastic gives that error message of differing types again. Closing and opening the file again removes the error.
I recently ran into a Cabal issue that I only managed to solve by manually installing transformers-compat with the -f transformers3 flag in my cabal sandbox before running cabal install for my project.
Is there any way to indicate in my application's .cabal file that I depend on a library so that it is built with the specific build flag?
Newer versions of Cabal let you specify constraints in your cabal.project.local or cabal.project file. For example:
constraints: hmatrix +openblas
Is there any way to indicate in my application's .cabal file that I depend on a library so that it is built with the specific build flag?
No, but in your case this is not actually a problem in the solver and is rather and uninformative error (caused by someone's less than judicious uses of flags).
Looks like it's not possible to specify such a dependency via the build-depends field in your .cabal file. buildDepends is defined as [Dependency], where data Dependency = Dependency PackageName VersionRange. You can use cabal install --constraint="transformers-compat +transformers3", though.
Looking at the transformers-compat.cabal file, I think that the solver should be able to figure out the correct flag assignment if you constrain your dependency on transformers appropriately. E.g. build-depends: transformers >= 0.3 && < 0.4 should force the solver to choose transformers-compat +transformers3. If this doesn't work, it may be a bug in the solver.
I also struggled for a long time to find a solution to this problem. I just found one! You have to modify the global cabal configuration file at ~/.cabal/config. Add a constraints line like this to the initial section of the file:
constraints: hmatrix +openblas
This enables the openblas flag for the hmatrix package. It will be used automatically the next time the package is installed. If there is a way to set such a flag locally for a sandbox, I could not find it.
You cannot do this with Cabal.
One way to do this is to use Stack. Edit your stack.yaml to include
flags:
transformers-compat:
transformers3: true
See also the section on flags.
cabal now supports an elegant way to do this similar to stack, through cabal.project configuration options.
package transformers-compat
flags: +transformers3
will add the flag transformers3 when building the package transformers-compat.
There are a couple of ways to constrain the version for installation.
Add lower and upper bounds to package versions in the cabal file like Mikhail mentioned above, example of such a file here
Additionally, you can override the settings in the .cabal file with the flag cabal install --constraint="bar-2.1"
To remove a specific version of a package:
In a sandbox you can unregister a version with cabal sandbox hc-pkg unregister bar-2.1
Global unregistering can be done with this command outside of sandbox ghc-pkg unregister bar-2.1
I'm trying to compile a package (git-annex) under OpenBSD and I'm hitting some weird issues.
I keep getting
Loading package gnuidn-0.2.1 ...
GHCi runtime linker: fatal error: I found a duplicate definition for symbol
c_isascii
whilst processing object file
/usr/local/lib/libidn.a
This could be caused by:
* Loading two different object files which export the same symbol
* Specifying the same object file twice on the GHCi command line
* An incorrect `package.conf' entry, causing some object to be loaded twice.
GHCi cannot safely continue in this situation. Exiting now. Sorry.
This was brought up here, here and here but it didn't help me at all. I have checked to see if I have different versions of different packages (which I don't, according to ~/.cabal/lib and 'ghc-pkg list') and I have even tried recompiling libidn without the c_isascii symbol, which only resulted in the same error but about a different symbol (stringprep_utf8_to_unichar).
So right now I have no idea what to do. Any ideas?
EDIT: Added 'ghc-pkg list' to the sources I've checked for conflicting packages.
I am not sure exactly what my question is as I get seriously turned around by autoconf/automake/libtoolize etc. Several of us are trying to autoconferize mbsystem. I've thrown a repo up of the work to date here:
https://bitbucket.org/schwehr/mbsystem
I'm trying to improve the netcdf setup to use nc-config, but am uncertain how to do this correctly. I am working on configure.in. It seems unable to find a header with AC_CHECK_HEADER("netcdfcpp.h") after INCLUDES="$INCLUDES ``$nc_config --cflags``" (pardon the incorrect back ticks) as taken from the gdl netcdf check. What is the correct way to update the path from nc-config --cflags?
http://gnudatalanguage.cvs.sourceforge.net/viewvc/gnudatalanguage/gdl/configure.in?revision=1.121
I then tried to use AX_PATH_GENERIC and get stuck on this error with m4_include([m4/ax_path_generic.m4])
Running autoconf ...
configure.in:29: error: possibly undefined macro: AC_SUBST
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure:12992: error: possibly undefined macro: AC_MSG_RESULT
Any help in getting better at creating a netcdf check that actually will work with funky non-standard install locations via nc-config and figuring out how to properly put a macro in the m4 directory would be a huge help.
A pointer to a package doing this really cleanly would be a super help. I've been looking at the netcdf, gdal, geos and gdl sources for examples. And things like the octopus netcdf check do not use nc-config... http://www.tddft.org/trac/octopus/browser/trunk/m4/netcdf.m4
The current setup with fink for netcdf 4.x:
nc-config --cflags --libs
-I/sw/opt/netcdf7/include -I/sw/include
-L/sw/opt/netcdf7/lib -lnetcdf
Thanks!
See Makefile.am: How to use curl-config and xml2-config in configure.ac? and substitute xml2/curl by netcdf.
Just use
PKG_CHECK_MODULES([libnetcdf], [netcdf])
in configure.ac, and then, in Makefile.am:
AM_CPPFLAGS = ${libnetcdf_CFLAGS}
bin_PROGRAMS = foo
foo_SOURCES = ...
foo_LDADD = ${libnetcdf_LIBS}
The "correct" way to use a third party m4 macro is to use aclocal (usually via automake) to generate aclocal.m4. If you are using automake, just add
ACLOCAL_AMFLAGS = -I m4
to Makefile.am and put
AC_CONFIG_MACRO_DIR([m4])
in configure.ac (after renaming configure.in).
If you are not using automake, add '-I m4' when you invoke aclocal. If you are not using aclocal, then you'll have to append the definition of the macro to the end of aclocal.m4 (and be careful to never run aclocal, as that will overwrite the file.)
There is no good example of a clean way to use conf scripts to do a build because using such scripts is an inherently flawed approach. A slightly cleaner approach is to stop using custom scripts and use pkg-config via PKG_CHECK_MODULES, but the cleanest way to do this is to educate your users. If the user wants to install the library in funky non-standard locations then they need to be educated enough to set LDFLAGS and CPPFLAGS appropriately.
I guess this would be a generic question on including libraries with existing makefiles within cmake; but here's my context -
I'm trying to include scintilla in another CMake project, and I have the following problem:
On Linux, scintilla has a makefile in (say) the ${CMAKE_CURRENT_SOURCE_DIR}/scintilla/gtk directory; if you run make in that directory (as usual), you get a ${CMAKE_CURRENT_SOURCE_DIR}/scintilla/bin/scintilla.a file - which (I guess) is the static library.
Now, if I'd try to use cmake's ADD_LIBRARY, I'd have to manually specify the sources of scintilla within cmake - and I'd rather not mess with that, given I already have a makefile. So, I'd rather call the usual scintilla make - and then instruct CMAKE to somehow refer to the resulting scintilla.a. (I guess that this then would not ensure cross-platform compatibility - but note that currently cross-platform is not an issue for me; I'd just like to build scintilla as part of this project that already uses cmake, only within Linux)
So, I've tried a bit with this:
ADD_CUSTOM_COMMAND(
OUTPUT scintilla.a
COMMAND ${CMAKE_MAKE_PROGRAM}
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/scintilla/gtk
COMMENT "Original scintilla makefile target" )
... but then, add_custom_command adds a "target with no output"; so I'm trying several approach to build upon that, all of which fail (errors given as comment):
ADD_CUSTOM_TARGET(scintilla STATIC DEPENDS scintilla.a) # Target "scintilla" of type UTILITY may not be linked into another target.
ADD_LIBRARY(scintilla STATIC DEPENDS scintilla.a) # Cannot find source file "DEPENDS".
ADD_LIBRARY(scintilla STATIC) # You have called ADD_LIBRARY for library scintilla without any source files.
ADD_DEPENDENCIES(scintilla scintilla.a)
I'm obviously quote a noob with cmake - so, is it possible at all to have cmake run a pre-existing makefile, and "capture" its output library file, such that other components of the cmake project can link against it?
Many thanks for any answers,
Cheers!
EDIT: possible duplicate: CMake: how do i depend on output from a custom target? - Stack Overflow - however, here the breakage seems to be due to the need to specifically have a library that the rest of the cmake project would recognize...
Another related: cmake - adding a custom command with the file name as a target - Stack Overflow; however, it specifically builds an executable from source files (which I wanted to avoid)..
You could also use imported targets and a custom target like this:
# set the output destination
set(SCINTILLA_LIBRARY ${CMAKE_CURRENT_SOURCE_DIR}/scintilla/gtk/scintilla.a)
# create a custom target called build_scintilla that is part of ALL
# and will run each time you type make
add_custom_target(build_scintilla ALL
COMMAND ${CMAKE_MAKE_PROGRAM}
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/scintilla/gtk
COMMENT "Original scintilla makefile target")
# now create an imported static target
add_library(scintilla STATIC IMPORTED)
# Import target "scintilla" for configuration ""
set_property(TARGET scintilla APPEND PROPERTY IMPORTED_CONFIGURATIONS NOCONFIG)
set_target_properties(scintilla PROPERTIES
IMPORTED_LOCATION_NOCONFIG "${SCINTILLA_LIBRARY}")
# now you can use scintilla as if it were a regular cmake built target in your project
add_dependencies(scintilla build_scintilla)
add_executable(foo foo.c)
target_link_libraries(foo scintilla)
# note, this will only work on linux/unix platforms, also it does building
# in the source tree which is also sort of bad style and keeps out of source
# builds from working.
OK, I think I have it somewhat; basically, in the CMakeLists.txt that build scintilla, I used this only:
ADD_CUSTOM_TARGET(
scintilla.a ALL
COMMAND ${CMAKE_MAKE_PROGRAM}
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/scintilla/gtk
COMMENT "Original scintilla makefile target" )
... and then, the slightly more complicated part, was to find the correct cmake file elsewhere in the project, where the ${PROJECT_NAME} was defined - so as to add a dependency:
ADD_DEPENDENCIES(${PROJECT_NAME} scintilla.a)
... and finally, the library needs to be linked.
Note that in the commands heretofore, the scintilla.a is merely a name/label/identifier/string (so it could be anything else, like scintilla--a or something); but for linking - the full path to the actual `scintilla.a file is needed (which in this project ends up in a variable ${SCINTILLA_LIBRARY}). In this project, the linking basically occurs through a form of a
list(APPEND PROJ_LIBRARIES ${SCINTILLA_LIBRARY} )
... and I don't really know how cmake handles the actual linking afterwards (but it seems to work)
For consistency, I tried to use ${SCINTILLA_LIBRARY} instead of scintilla.a as identifier in the ADD_CUSTOM_TARGET, but got error: "Target names may not contain a slash. Use ADD_CUSTOM_COMMAND to generate files". So probably this could be solved smarter/more correct with ADD_CUSTOM_COMMAND - however, I read that it "defines a new command that can be executed during the build process. The outputs named should be listed as source files in the target for which they are to be generated."... And by now I'm totally confused so as to what is a file, what is a label, and what is a target - so I think I'll leave at this (and not fix it if it ain't broken :) )
Well, it'd still be nice to know a more correct way to do this eventually,
Cheers!