21–30 of 35 posts
Very good. I wish you all the success. But I have a (side) question. You are using Makefile while targeting non-nix platforms. Why? It seems to me it is the strangest combination ever.
How different is this from Intel's vtune amplifier? I used vtune amplifier to get the memory profiles for some c++ code I had written before.
Is it free? Can the code be verified for backdoors? Does it work on non-intel chips?
Very good. I wish you all the success. But I have a (side) question. You are using Makefile while targeting non-nix platforms. Why? It seems to me it is the strangest combination ever.
For convenience! Make is a powerful software and GNU Make is readily available for Windows, e.g. as part of MinGW. I also actively use it for my projects, because it's just kind of always there when you need a build system and you can put together an initial Makefile real quick.
Considering GNU Make is not itself available in Windows and you should install MinGW for getting make.
Earlier quoted context omitted.
For convenience! Make is a powerful software and GNU Make is readily available for Windows, e.g. as part of MinGW. I also actively use it for my projects, because it's just kind of always there when you need a build system and you can put together an initial Makefile real quick.
Isn't all of these arguments applicable to CMake? Considering GNU Make is not itself available in Windows and you should install MinGW for getting make.
Earlier quoted context omitted.
Isn't all of these arguments applicable to CMake? Considering GNU Make is not itself available in Windows and you should install MinGW for getting make.
Windows is a pain to program on, and MinGW alleviates that somewhat. I do use CMake though, but I still want to use "normal" clang, so I have to generate a unix makefile. I don't want to maintain two sets of build systems.
It's really not, if you know how to do it. But that goes for any OS out there. I mean, put a seasoned visual-studio-on-windows-only dev in front of a linux box and tell him to set up the build of a non-trivial application and watch what happens. Chances are pretty high the answer is 'linux is a pain to program on' :]
but I still want to use "normal" clang, so I have to generate a unix makefile
https://blogs.msdn.microsoft.com/vcblog/2017/03/07/use-any-c... it's still relatively young but seems to work quite ok
Earlier quoted context omitted.
> MTuner is a C/C++ memory profiler and memory leak finder for Windows, PS4, PS3, etc. I don't see any mention of Mac at all in the Readme, and I find the "etc" part confusing. For example, I use FreeBSD. PS4 is based on FreeBSD. Does FreeBSD go under the "etc" part? If not then what does?
> MTuner supports Windows, PlayStation 4 and PlayStation 3 > out of the box. Additionally, any platform with GCC or > Clang based cross compiler can easily be supported with a > little extra work. Instrumentation API comes with full > source code which means it’s a matter of porting a few > routines to get it up and running on additional platforms. http://mtuner.net/doc/overview_compilers.html
Earlier quoted context omitted.
Isn't all of these arguments applicable to CMake? Considering GNU Make is not itself available in Windows and you should install MinGW for getting make.
Windows is a pain to program on, and MinGW alleviates that somewhat. I do use CMake though, but I still want to use "normal" clang, so I have to generate a unix makefile. I don't want to maintain two sets of build systems.
Very good. I wish you all the success. But I have a (side) question. You are using Makefile while targeting non-nix platforms. Why? It seems to me it is the strangest combination ever.
For convenience! Make is a powerful software and GNU Make is readily available for Windows, e.g. as part of MinGW. I also actively use it for my projects, because it's just kind of always there when you need a build system and you can put together an initial Makefile real quick.
... I don't think we have the same definition of "readily available". First you have to choose between two dozens MinGW distros, some up-to-date, some not, choose if you want to use Windows or Unix paths, etc etc.
Earlier quoted context omitted.
Windows is a pain to program on, and MinGW alleviates that somewhat. I do use CMake though, but I still want to use "normal" clang, so I have to generate a unix makefile. I don't want to maintain two sets of build systems.
Windows is a pain to program on, It's really not, if you know how to do it. But that goes for any OS out there. I mean, put a seasoned visual-studio-on-windows-only dev in front of a linux box and tell him to set up the build of a non-trivial application and watch what happens. Chances are pretty high the answer is 'linux is a pain to program on' :] but I still want to use "normal" clang, so I have to generate a unix…
Earlier quoted context omitted.
Isn't all of these arguments applicable to CMake? Considering GNU Make is not itself available in Windows and you should install MinGW for getting make.
Windows is a pain to program on, and MinGW alleviates that somewhat. I do use CMake though, but I still want to use "normal" clang, so I have to generate a unix makefile. I don't want to maintain two sets of build systems.
I am programming Windows since version 3.0, have experience across multiple types of operating systems, had a phase of my life of being a GNU/Linux zealot and where I like to spend my time is on Windows.
I live on my IDEs and there is hardly a CLI feature that can't be better done within a REPL environment.