Will Geany create backup files using the OpenVMS Files-11 version naming? For example, x.txt.3 for the third version of x.txt
Geany core is not supporting such a feature. But there is a plugin called SaveActions available providing a similar feature. However, usually I ask people in such situations to use some VCS as git or mercurial which in most cases makes more sense than to keep many files.
Related
I have a tool in C that needs libpng, zlib and lcms libraries. On unix I get these dependencies via pkg-config, but on Windows I can't rely on it, so for users building the library it's a massive hassle to obtain and build these dependencies manually.
How can I automate obtaining these dependencies in the most Windows-native way? I know MinGW helps, but that's a bit of a cop-out. I'd like to learn how to do it with the Microsoft toolchain.
Is there any point in searching for shared non-Microsoft libraries on Windows, or should I go straight for statically linking my own?
If I were to download and build the libraries as part of my build script, what should I use? (nuget? curl? ftp.exe?)
It seems like Microsoft is discouraging use of NuGet for C? https://github.com/Microsoft/vcpkg/blob/master/docs/about/faq.md#why-not-nuget
I recommend looking into Nuget. It's fast becoming the Microsoft standard for these sort of things. A lot of people think Nuget is just for .NET, but it works great for VC++ too. I have had a great deal of success setting up Nuget servers in my company to serve headers and compiled libs, and I've gotten all of our automated build systems to create these things automatically. I'm not going to spell out all the details here, but it basically comes down to performing your build, creating an MSBuild XML snippet to set up the precompiler and link options automatically, and then packaging all those bits (headers, libs, XML) in the correct way. When done correctly, it's just a two step process to use an existing package in a new project -- establish the Nuget reference and then add the #includes into your code. You don't even need a server -- you can source them directly from a directory of your own control.
https://learn.microsoft.com/en-us/nuget/create-packages/native-packages
Can anyone suggest a multiple precision library that comes with pre-built windows binaries. I need to use it use with an existing Visual Studio 2010 project (or where I can get pre-built binaries for win7 64bit for GMP).
I have tried and failed to compile GMP and MPIR and other projects none of them work with various frustrating and ambiguous errors. Unfortunately time pressures are getting to me and what I need to implement is simple if I can get the library built/downloaded.
I need floating point support so a bigint library is not enough.
Thanks,
http://www.cs.nyu.edu/exact/core/gmp/ has the following package with dlls:
dynamic GMP library and header file for Visual C++: gmp-dynamic-vc-4.1.2.zip
They also have the source project files if you want to try recompiling with a different version at some point.
Your best bet is MPIR. I've built MPIR and MPFR using VS 2010 so it is possible. My Windows system is down at the moment but here are some notes I made.
Download MPIR, unpack, and rename directory to just be "mpir" - remove any version numbers.
Find and follow the readme file that documents installing VSYASM.
Run "mpir_config.py" with Python 3.x to create the project files.
Change the number of parallel builds to 1.
Select a particular target (say "lib_mpir_k8") and it should build.
MPIR also includes a couple of batch files so you can do a command line build using configure.bat and make.bat. I find it is easier than the GUI builds.
IIRC, to build MPFR, I had to modify some of the Include directories but my notes are a little too cryptic.
The MPIR mailing list is quite helpful, too.
We have a large C project with development happening on Linux, Mac OS and Windows. Most of our Windows developers use MSVC -- for example, the free edition of Visual C. Oftentimes .c source files are added, renamed or deleted, and we find it very frustrating to keep the Visual C project in sync with these changes to directories.
Developer A might add newfile.c, check it in to Subversion and happily continue work.
Developers B, C, etc. update to the latest revision. Then when they compile in MSVC they get an error (buried somewhere in the huge compile output) saying the linker can't find such-and-such symbol. They then need to look to see what files have changed and manually add that to the project tree in MSVC.
(Developer A might be on Unix where build scripts tend to automatically find the right files to compile, and not realise how much work they've just created for B and C!)
My question is, is there a way to tell MSVC to consider every .c file in a directory as part of the project?
Update We have build scripts that can create initial MSVC project files. But there's a signicifant amount of customisation that gets done after this (pointing to libraries, etc.) which would be blown away each time the scripts were rerun merely to add a new file.
Given how many large projects there are out there, I'm kind of surprised Visual Studio requires such manual work by each developer just to pick up new files added by others.
I'm going to optimistically hold out for a better solution for now...
I don't think Visual Studio can do what you want (but would be glad if I'm proved wrong!).
What works for me is to use cross platform project files. Take a look at CMake, which allows you to define the structure of your project in a platform independent text based format. Then on each platform these project files are processed with a tool that then automatically generates the appropriate thing, which could be Makefiles, Visual Studio solution and project files, etc.
If this is really a serious problem, I would recommend writing a script which updates VS project file accordingly with directory contents.
I know, it must be a silly question.
Assume I have a library using an autotools build system.
I have all that configure, configure.ac, Makefile.am, config.h and may other files in my project root folder. Some of them wre written by a developer, others are generated by autotools.
The question is: if I use a version control system (in my case - hg) - which of all that autotools files should be tracked by a VCS and which shouldn't (hgignore'd)?
Thanks,
Serge
I think the best procedure is to only put files under version control that are not generated - people working with the VCS are developers and should have the autotools installed on their machines, checking in generated files will only cause trouble for them.
On the other hand you have to make sure that source-level distribution is done with all generated files in place, so that non-developers are able to build the software without the autotools installed.
There are two schools of thought on this:
"I want to see the project exactly as it was at time/version X"
"I can always re-generate anything which was automatically generated later"
I generally fall into the latter group personally, but the former can be nice if there are/were problems with the build system in some specific version that you probably don't have installed any more.
In your example configure and config.h are both (probably) autogenerated, so if you're going to include them in version control I'd be inclined to include the Makefile.ins too.
In my projects this usually means having no more autotools related files than configure.ac, Makefile.am, the documentation if it's GNU and a directory called m4 which includes any custom/non-standard macros my configure.ac requires.
There is few files with .c anf .h extensions (cmdline.c cmdline.h core.c core.h and so on) in src directory, also there is one file "MakeFile" without extension. Is there any possibility to build these source files into some executable file on Windows 7 (64bits) ? I think i need to download compilers for C or some sdks right?
Yes.
You need to:
download and install a C/C++ compiler (I recommend TDragon's distribution of MinGW ),
add the compiler to your PATH (the installer can do it for you most of the cases); verify it's done by opening cmd.exe and typing gcc -v and mingw32-make -v, both should give you half a screenful of version information if your path is set correctly,
via cmd.exe, navigate to the folder in which the Makefile resides and call mingw32-make.
From now on everything should compile automatically. If it doesn't, post the errors.
Update:
First of all, it'd be useful for you to get the MSys package. Install it and you'll have a more recent version of make (use it instead of mingw32-make from now on).
About the CreateProcess bug, it has to do with the system PATH variable being too long. You'd need to do something like this:
open cmd
execute set PATH=c:/mingw32/bin;c:/msys/1.0/bin (change the paths here to reflect your own installation if it's different)
then as before: navigate to your project's directory, run make. Everything should be smooth now if you're not missing any external libraries.
BTW- remember not to install MinGW or MSys in directories with spaces.
I am not a Windows Developer..
But still as per my knowledge. Visual Studio (i.e 2008, I guess) has the ability to read the Makefile.
Please have a look at it..and if needed change this makefile to their format..
There are many opensource product which are platform independent..and they get compiled on both OS with the just Makefile they provided.
Or else use 'cygwin'
Developer C++ works in windows but it is actually GCC code bought into Windows, Is anyone familiar about the procedure they used to convert the linux ( .sh) to executables ??
I think i need to download compilers for C or some sdks right?
A compiler certainly, but what additional libraries you may need will depend entirely on the code itself. A successful build may also depend on the intended target of the original code and makefile. The makefile may be a GNU makefile, but there are other similar but incompatible make utilities such as Borland Make and MS NMake. If it is a simple build, you may be able to avoid the makefile issue altogether and use the project management provided by an IDE such as Visual C++ 2010 Express.
If you do not know what this code is or what it does and what it needs to build, you are taking a risk building it at all. Maybe you should post a link to the original source so that you can get more specific advice on how to build it.
[EDIT]
Ok, now looking at the code you are attempting to build, it is a very simple build, so if you wanted to avoid using GNU make, then you could just add all the *.c files in the src folder to a project in your IDE and build it.
However there is one serious gotcha, it uses the BSD sockets API and Linux system headers. You will need to first port the code to Windows APIs such as WinSock (very similar to BSD Sockets), or build it under Cygwin (a sledgehammer for a nut somewhat). There may be other Linux dependencies that need sorting, I have not looked in detail, but it looks fairly simple. That said, if you did not have the first clue regarding compiling this stuff, then perhaps this is not a task you could do?
Of course compiling the code may only be half teh problem, if it was designed to run on Linux, there may be run-time dependencies that prevent it running on Windows. Again I have not looked in detail.
Also looking at the code, I would suggest some caution, this may not be the best quality code. That may be unfair, but one obvious flaw and an indication if inexperience is the lack of include guards in the headers.