| |
Jammer
Registered: Nov 2002
Posts: 1289 |
Release id #185343 : VICE 3.4
Since 3.4 Mr Wegi's loader stopped working - it seems to init drive and go idle. Any solution to that? Tweaking settings gives no results. |
|
... 28 posts hidden. Click here to view all posts....
|
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Plain Makefile's will do fine with projects using little to no external libraries and when you only support a few OSes and a single compiler. Command line things like an assembler can be done with plain Makefile's and perhaps a bunch of #ifdef's to handle platform-dependent code.
I prefer plain Makefile's too, when feasible, I'm not a fan of autotools, but so far it's the most logical thing to use for us, seeing the amount of OSes, libraries and compilers we need to support.
I've tried a lot of build systems, one even suggested cat'ing .c files together to speed up compilation =)
We dumped MVSC support because it was a pain in the arse to maintain: basically a whole lot of brittle scripts going through the source to create MVSC crap and nobody used it.
I'm not saying I'll never consider another build system, but in the end it comes down to people actually willing to put in the work to show buildsystem X, Y or Z is better. And then maintain it. |
| |
Zirias
Registered: Jan 2014
Posts: 48 |
Quoting hedningQuoting CompyxVICE's build system hasn't supported MSVC for quite a while now. If you want to build VICE on Windows from source you'll need msys2, unless Visual Studio supports autotools projects. How can we get them to do that again then? The bulkyness of today's versions is unbearable. 95% of the daily VICE users must be Windows users.
So what gives you the idea this has anything to do with supporting MSVC? Vice is written in C, and Microsoft's compilers don't support newer C standards at all -- they seem to only care about C++. Nowadays, it makes no sense at all to support building a C project with MSVC. You use either GCC or LLVM/clang, both are available in MSYS2 for Windows :)
I have no idea whether the VICE code base actually uses any C99 and newer language features, but that's generally #1 reason for kicking out MSVC support. #2 is probably the burden to maintain multiple build systems.
As for performance issues of recent VICE versions built for Windows, I never really noticed them myself, but I don't use it a lot on Windows and the Windows machine I use has a pretty fast CPU ...
Any idea whether these issues are more likely in VICE's code or in other libs / build settings / etc? I could maybe try to create a build using my MXE toolchain and see whether it uses less CPU ;) |
| |
Zirias
Registered: Jan 2014
Posts: 48 |
Quoting CompyxPlain Makefile's will do fine with projects using little to no external libraries and when you only support a few OSes and a single compiler.
Well, you *can* do more complex stuff, especially if you don't restrict yourself to "portable make" but require a specific flavour like e.g. GNU make.
Because I don't like the huge complexity of GNU autotools, I started developing my own system using only GNU make "metaprogramming" here: https://github.com/Zirias/zimk :)
Don't get me wrong, I would never suggest a complex project like VICE adopting this, of course it doesn't have all the features GNU autotools provide, and it totally lacks in documentation -- but I *do* use it myself, so just mentioning it here as an example what can be done with "plain make". E.g. it handles dependencies with pkg-config :) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
VICE uses some C99 features, such as the fixed with integer types (stdint.h) and bool (stdbool.h). I tried to use the new printf format specifiers in inttypes.h, but the Windows C runtime doesn't support those, so in stead of:
size_t x = 42;
printf("%zu\n", x);
I have to revert to the old C89 'trick' to print a size_t:
size_t x = 69;
printf("%lu\n", (unsigned long)x);
Perhaps '%llu' and `unsigned long long` on 64-bit, if Windows even supports that, haven't checked yet.
We have a way of generating a CMake project from trunk, which should be importable into VS, I'm not sure how useful that would be seeing the abominable state of MS's C support.
I tried the CMake route with VS, but I got a lot of missing .lib files for Gtk3 etc. There's supposed to be a tool 'vcpkg' to install those libs for use in VS, but on my box VS didn't see the libs, leading to manually adding a lot of libs using a horrific UI, so I deleted VS. |
| |
Zirias
Registered: Jan 2014
Posts: 48 |
Quoting CompyxVICE uses some C99 features, such as the fixed with integer types (stdint.h) and bool (stdbool.h). I tried to use the new printf format specifiers in inttypes.h, but the Windows C runtime doesn't support those, so in stead of:
size_t x = 42;
printf("%zu\n", x);
I have to revert to the old C89 'trick' to print a size_t:
size_t x = 69;
printf("%lu\n", (unsigned long)x);
Perhaps '%llu' and `unsigned long long` on 64-bit, if Windows even supports that, haven't checked yet.
There are two ways around this when using MinGW to link to MSVCRT.DLL.
1. Do something like this:
#include <inttypes.h>
#include <stdio.h>
#ifdef _WIN32
# ifdef _WIN64
# define PRI_SIZET PRIu64
# else
# define PRI_SIZET PRIu32
# endif
#else
# define PRI_SIZET "zu"
#endif
int main(void)
{
size_t mySize = 24;
printf("%" PRI_SIZET "\n", mySize);
}
2. Let MinGW link some code to your executable working around this by adding
#define __USE_MINGW_ANSI_STDIO 1
I'd assume %lu could break on 64bit windows, as a size_t is probably 64 bits wide, but a "long int" still has only 32bit (Windows 64bit uses the LLP64 data model, unlike most Unixes that use LP64)
Quoting Compyxso I deleted VS.
Unless you want to create .NET code, best course of action ;) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Interesting. I'll try the first option first, since we also cross-compile Windows bins on a Debian box.
The second option appears to require some additional fuckery, and it probably won't work with VS (not that I personally care).
And yes, deleting VS felt pretty good :=) |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
what do people use in lieu of VS? |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
I use Vim and a terminal. |
| |
Zirias
Registered: Jan 2014
Posts: 48 |
Same here. And there are many other nice text editors with coding support (e.g. "vs code") if you *really* don't like vim.
And for those in need of a full-blown IDE, there are several alternatives as well (e.g. eclipse, although I think that's a monster, but there are others as well) |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
sadly VSCodes C/c++ support is x86 only.
Eclipse is a horror show, a text editor should be instant on anything with 3 or more Ghz, and it fails.
SlickEdit supports linux(they have a Raspberry Pi beta now it seems).
the true power of VS however is the debugger, that is what I would like a linux version of.
Edit-and-continue would also be sweet. |
| Previous - 1 | 2 | 3 | 4 - Next |
