ich hab mich heute weiter mit vs community 2019 auseinandergesetzt. wie gesagt ist die node-unterstützung total super.
nun wollte ich es mal auf die spitze treiben. auf github findet man die quellcodes des alten windows 3.11 file managers. ich habe sie direkt von der ide aus gecloned und vs hat auch gleich versucht eine projektmappe daraus zu bauen. natürlich erstmal mit dutzenden von errors. das lag aber zumeist an absoluten pfaden, die der ersteller des repositories drin hatte. der hammer war ein verweis auf "c:\administrator\libs\ntdll.lib" (oder so) in einer projektdatei für ein älteres visual studio. vs 2019 hatte diese ausgewertet und wollte unbedingt diese lib in diesem verzeichnis haben. war schwer zu finden, denn die 'find in files'-funktion hatte diese datei ausgelasen. aber nun geht alles.
übrigens ist der filemanager uralter c-code, noch vor c90. dass vs 2019 den noch compilieren kann, ist ein weiteres lob wert.
ach ja, der win311-filemanager ist inzwischen open source. microsoft selbst hat ihn ebenfalls auf github veröffentlicht.
einziger wermutstropfen bisher: ich wollte eine optionale extension für javascript installieren, doch vs2019 wollte vorher ohne ende gigabytes an dotnet-bibliotheken runterladen. das habe ich dann besser sein gelassen. ich vermute mal, das liegt nicht an vs, sondern am entwickler der extension. die hat er wohl quick and dirty in c# gecodet.
Hallo,
ich arbeite mich derzeit in die GNU Autotools ein. Ich bin soweit gekommen, dass ich ein Projekt unter Windows UND Linux übersetzen und auch ausführen kann. So weit so gut.
Ich nutze in dem Zusammenhang auch die TestSuite von GNU. Sie laufen auch wunderbar unter Windows, nur unter Linux nicht. Das Problem liegt auf der Hand, eines der Scripte ist beispielhaft folgendermaßen aufgebaut:
AT_SETUP([Version class size])
AT_KEYWORDS([version size])
AT_CHECK([../../unittest/src/version/classsize.exe], [0], [], [])
AT_CLEANUP
Die GNU AutoTools bieten doch sicherlich die Möglichkeit, eine Art Platzhalter für die Dateierweiterung einzusetzen, oder? Falls nicht, wie könnte ich das Problem in den Griff bekommen?
Vielen Dank im Voraus
Torsten
Hat sich schon jemand näher damit beschäftigt?
Die Files Übersicht ist auf jeden Fall schon mal interessant.
Was ich noch gesehen habe, sind irgendwelche Funktionen, die lang brauchen. Aber woran liegt das? Ich fand das nicht immer einleuchtend. Gibt´s dazu noch mehr Infos, die ich übersehen habe?
Ach ja, und noch weiteres Randdaten zum System: Debian 9 Stretch mit backports-Kernel. Läuft als Server auf VirtualBox und wird mit "xrdp" über die Windows-Remotedesktopverbindung angesprochen.
Grüsse, Jan
Hmm.
Was ich nun noch herausgefunden habe, wenn ich den Ausgabeordner "debug" nach dem Build komplett lösche,
und nochmals auf Build klicke wird nicht neu kompiliert:
Diese Ausgabe erhalte ich:
Build with surface heuristics started at 09:55:32
Build completed in 00:00:00.021
Also irgendwie erkennt er nicht dass das Ausgabeverzeichnis gelöscht wurde. Woran kann das liegen?
Ein C++-Compiler hat nichts mit einer GUI zu tun.
Echte Open Source Compiler sind gcc und clang. Aber auch Visual Studio darf ohne Bezahlung für kommerzielle Projekte genutzt werden.
Für die GUI brauchst du eine passendes GUI-Bibliothek. Ein Beispiel dafür wäre Qt.
Benötigst du eine IDE? Visual Studio ist eine. QtCreator ist eine andere, auf Qt zugeschnittene.
@laura555 Du Fragst in einem über ein Jahr alten Thread einen User der seit mehr als einem Jahr nicht mehr online war. Wenn Du eine Frage hast dann stelle die bitte in einem neuen Thread im Compiler- und IDE-Forum.
Danke schön!
Mein erster Eintrag verweist auf ein GitHub Profil wo nix zum angefragten Package steht. Und dass man auf hellix.com doch fündig werden kann versteht sich aus der Hompepage jetzt auch nicht von alleine. Die gefundenen alten Links auf hellix waren ja nicht mehr gültig. Aber nochmal, danke.
Ich habe es grad mal getestet mit dem Fehler in dem Programm der für das heimliche ausführen im Hintergrund gesorgt hat. Ich habe tatsächlich schon vorher in beide Tabs geschaut aber ich glaube ich war lediglich blind denn unter Details stand die Anwendung tatsächlich drin. Habe ich es mir echt unnötig schwer gemacht Habe den Rechner bestimmt einige zig Male neu gestartet -.-
Und ich war kurz davor Windows neuzuinstallieren da ich dachte dass damit was kaputt is
Hab es erstmal so gelöst:
#if defined(_MSC_VER)
#if _HAS_CXX17
#include <filesystem>
namespace fs = std::filesystem;
#define __HAS_FILESYSTE
#endif // _HAS_CXX17
#elif defined(__MINGW32__) || defined(__GNUC__)
#if __cplusplus >= 201703L
#include <experimental/filesystem>
namespace fs = std::experimental::filesystem;
#define __HAS_FILESYSTE
#endif // __cplusplus >= 201703L
#endif
Danke für Eure Infos, Gruß Helmut
ps. GNUC bin ich mir noch nicht sicher, probiere ich wahrscheinlich Sa. aus.
Ich habe zwar ein embedded System und kompiliere nicht nativ aber bei meinem (onboard) ST_Link gibt es ein Konfig Script (für den Debugger). Hier ist hinterlegt mit welcher Frequenz er sich mit dem Gerät verbindet, sowie der Name des Geräts.
Vielleicht gibt es bei dir ja was vergleichbares?
Hey vielen Dank.
Das war in der tat ein guter Hinweis:
Ich habe das nostartupfiles jetzt entfernt. Jetzt linkt er auch korrekt
Falls es jemanden interessiert:
Ich hatte danach noch ein weiteres Problem was ich lösen konnte: Leider wurden die statischen Konstruktoren nie aufgerufen.
In meinem Startup Script sind die folgenden Schritte deifiniert:
/**
**===========================================================================
** Program - Reset_Handler
** Abstract: This code gets called after a reset event.
** 1. Call system initialzation routine
** 2. Copy .data section from ROM to RAM
** 3. Clear .bss section (Zero init)
** 4. Run static constructors
** 5. Enter main
** 6. Loop forever if returning from main
**===========================================================================
*/
Es hat sich herausgestellt das irgendjemand einfach den Teil (4) auskommentiert hat :O.
Also Falls jemand ein Ähnliches Problem hat, dass die statischen Konstruktoren nicht auferufen werden, prüft euer startup script
Vielen Dank aufjedenfall für eure schnelle Hilfe und Denkanstöße
