@Swordfish sagte in IDE Empfehlungen für Linux:
@wob sagte in IDE Empfehlungen für Linux:
Richtige Programmierer nutzen vi
So ein Quatsch. Die beißen Lochkarten mit den Zähnen aus.
Ok, das stimmt natürlich auch wieder. Da hast du mich überzeugt.
...und noch was:
"-> Die Tipps zum Übertakten habe ich von hier: https://miguelangelantolin.com/raspberry-pi-3-b-overclocking/ (-> Einfach "1550" mit "1500" ersetzen!!)"
Wenn schon übertakten, dann wenigstens den GPU-Speicher auf das Minimum (?) von 16MB setzen, damit ein wenig mehr zum Kompilieren übrig bleibt!
(Siehe vorletzter Post)
Und mit den Übertakten habt ihr recht, damit muss man vorsichtig sein... habe das Raspi (im Gehäuse, aber ohne Deckel) nun in den Serverraum gestellt wo es ein wenig wärmer ist. Und schon macht das Ding Stress. (Exakt gleiches Netzteil & USB-Stromkabel, daran kann es schon mal nicht liegen...)
Das geht so einfach nicht.
Geh wie folgt vor:
Suche die Datei "C:\Users\UserName\AppData\Local\Microsoft\VisualStudio\15.0_a404cb42\privateregistry.bin"
Lade diese Sturktur Datei, dann im Registry Editor. (ich habe es als VS-2017 geladen)
Dann müsstest Du die Einträge hier finden:
HKEY_USERS\VS-2017\Software\Microsoft\VisualStudio\15.0_a404cb42\ApplicationPrivateSettings\Platform\ProjectMRU
Die Pfade sind versionsabhängig.
Die API Funktion, die hinter dem steht ist: RegLoadAppKey
"preLaunchTask": "build" hat alles gelöst in der launch datei
in meinen fall nicht build sondern marvin
{
"version": "0.2.0",
"configurations": [
{
"name": "(gdb) Launch",
"type": "cppdbg",
"request": "launch",
"program": "D:\\Weiteres\\Microsoft VS Code\\projekt\\a.exe",
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceFolder}",
"preLaunchTask": "marvin",
"environment": [],
"externalConsole": true,
"MIMode": "gdb",
"miDebuggerPath": "D:\\Weiteres\\Mingw\\bin\\gdb.exe",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
]
}
]
}
Ich bedanke mich für die Hilfe. Schönen Tag noch
Zur Not kannst du auch direkt -lsomelib reinschreiben. Nicht, dass das gutes cmake wäre, funktioniert aber
Ich habe irgendwo z.B. mal schnell target_link_libraries(testpostgres -lpqxx -lpq) geschrieben, auch wenn man natürlich sonst lieber target_link_libraries(someprogram SomeLib::Whatever) haben sollte.
Edit: ich sollte besser lesen. Geht es hier gar nicht um das Linken einer Library an eine ausführbare Datei, sondern um das erzeugen einer Library selbst? Dann sind meine Hinweise natürlich völlig unzureichend.
Hurra, wieder ein kleiner Erfolg.
Dank eurer Hilfe kann ich nun Programme Builden und Ausführen.
Jetzt ist nur noch ein kleiner Fehler im Programm drinnen, der das Programm beim Ausführen beendet.
Aber das ist denke ich auch lösbar.
Vielen vielen Dank für eure Hilfestellungen und eure guten Tipps.
Weiß auch nicht, warum ich nicht auf dieses Ergebnis gestoßen bin (schlechte Suchbegriffe gewählt ). Die erste Option scheint zu Funktionieren.
Ich werde mich da aber wohl noch mehr einlesen müssen, um das Problem vollständig zu verstehen...
Danke dir.
Hallo,
der Thread hat zwar schon einen langen weißen Bart aber ich bin nun just über diesen gestolpert. Da auch im angloamerikanischen Internetsektor keine Lösung für dieses oft gefragte Problem exponiert wurde, hier mal meine Lösung für die vom Threadersteller eingestellte Frage:
1.) Die WinSDK\Samples\multimedia\directshow\baseclasses erstellen und zwar mit der gleichen Konfiguration wie auch das gewünschte Beispiel erstellt wird.
Der Pitfall ist nämlich die Defaultkonfiguration: Erstellen->Konfigurationsmanager-> „Debug_MBSC“ – richtig heißen muss es aber wie von allen Beispielen vorausgesetzt: „Debug“
Update: Es gibt jetzt zwei weitere Themes:
Ein selbst erstelltes, ist ziemlich "fruchtig"
OneDark Theme vom Atom Editor (inkl. creatortheme). Gefällt mir zur Zeit noch besser als das dunkle VS theme.
Und gerade wenn man in so einem Header dann noch boost mit drin hat, glaube ich nicht, dass das bei deiner compilezeit einen unterschied von nur 100ms ingesamt macht.
Kommt darauf an um welche Boost Headers es geht und wo man die sonst noch überall braucht. In "meinem" Projekt bei meinem letzten Job hatten wir quasi überall Boost drinnen. Weil C++98 und irgendwoher müssen die shared_ptr und Co ja kommen. Dementsprechend waren boost/shared_ptr.hpp und boost/scoped_ptr.hpp auch mit im Common.h.
Wenn man natürlich anfängt da boost MPL Sachen mir rein zu nehmen oder Boost.Format, Regex etc. gehört man natürlich gehauen.
Vielleicht hilft es auch zu beschreiben, wie du vorgehst.
Ich habe mehrere Varianten gerade probiert (also leere Dateien anlegen), wie beispielsweise den Datei Assistenen für leere Dateien oder direkt mit Einbindung in das Projekt.
Ich kann deinen Fehler nicht reproduzieren.
Ich verwende Post-Build Event in den Teilprojekten, die primär diese Zusatzdateien benötigen...
Wenn also die DLL die Sprachdateien braucht, dann kopiert dieser Buildprozess die benötigen Dateien mit in dem Post-Build Event.
Habe das Problem erkannt.
Die Abängigkeiten in der Solution waren nicht (mehr?) richtig gesetzt.
Durch setzen der Referenzen war das Problem zwar auch behoben. Allerdings war das wie vermutet nicht der richtige Ansatz.
Sprich: Änderung in lib -> keine direkte refrence in exe auf lib -> Abghängigkeit in Solution nicht gesetzt -> exe kompileren -> lib kompiliert nicht mit.
Habs gerade mal unter freebsd ausprobiert. bsd make scheint überhaupt keine impliziten regeln zu besitzen. Das scheint eine gnu make erweiterung zu sein.
Daher ist klar wieso das nicht funktioniert.
Es stellt sich aber weiterhin die Frage wiso du auf die explizite main regel verzichten möchtest, wo doch in der clean regel main bzw main.o referenziert werden