Verzeichnisnamen für Programmbibliotheken in Projekten


  • Gesperrt

    Gibt es genormte oder übliche Verzeichnisnamen für Programmbibliotheken in Projekten. Also gelesen habe ich schon z.B. extlibs, external, deps. Gibt es z.B. einen Unterschied in der Bedeutung zwischen dependencies und libraries?



  • bin, lib, shared sind so die Verzeichnisnamen, die mir so begegnet sind, manchmal mit den Postix 64 oder 32.


  • Gesperrt

    @mgaeckler sagte in Verzeichnisnamen für Programmbibliotheken in Projekten:

    bin, lib, shared sind so die Verzeichnisnamen, die mir so begegnet sind, manchmal mit den Postix 64 oder 32.

    Ja, habe es glaube ich missverständlich geschrieben, ich meinte nicht die *.dll bei dynamischem linken, sondern *.lib Dateien (bei msvc).

    Edit: Habe es immer noch nicht besser geschrieben. Tut mir leid...



  • @titan99_ Dann nur lib(32/64) das macht aber wirklich jeder so, wie er/sie es mag.


  • Gesperrt

    @mgaeckler Ja, wenn das Projekt eine Programmbibliothek ist. Ich meine aber, wenn man in ein Projekt externe Programmbibliotheken einbindet, diese aber irgendwo im Projektverzeichnis haben möchte und auch kompilieren möchte.

    Also z.B. um es mit cmake einzubinden:

    include_directories("${CMAKE_CURRENT_SOURCE_DIR}/extlibs/freetype2/include")
    add_subdirectory("${CMAKE_CURRENT_SOURCE_DIR}/extlibs/freetype2")
    

    Edit: Also Rolling Release ist dafür der falsche Ausdruck, nehme ich an, da er laut Wikipedia für Betriebssysteme gilt.

    Ich dachte bisher gar nicht daran, aber es handelt sich um Quellen/sourcen von Programmbibliotheken, die noch kompiliert werden müssen. Bin etwas müde, aber vielleicht sind sie auch schon kompiliert zum Teil.



  • @titan99_ sagte in Verzeichnisnamen für Programmbibliotheken in Projekten:

    Gibt es z.B. einen Unterschied in der Bedeutung zwischen dependencies und libraries?

    So wie ich den Begriff verwende, ja. Eine "Dependency" kann für mich auch ein eigenständiges Programm sein, dass z.B. während des Build-Prozess irgendwelchen Code oder Tabellen generiert die dann z.B. in das eigentliche Programm eingebettet werden. Oder es kann ein anderes Programm sein, dass später als separater Prozess von meiner Software gestartet wird. Oder irgendwelche Grafiken und andere Nutzdaten, die in irgendweiner Form "kompiliert"/vorverarbeitet werden müssen, z.B. um sie in ein für die Zielplattform geeignetes Format zu überführen oder überhaupt erst zu generieren. Oder eine Doxygen-Dokumentation in HTML, die während des Build-Prozesses aus den Quellen generiert wird. Diese wäre z.B. eine "Dependency" des Target "Kompletter Build mit Dokumentation".



  • @titan99_ Ich würde "third-party", "dependencies" oder "deps" vorschlagen.


  • Gesperrt

    @hustbaer Im Moment tendiere ich zu ext als Abkürzung für external, dann hat es gleich viel Buchstaben wie src. Dadurch hat es auch etwas ästhetisches, finde ich.



  • Ist sicher auch OK.



  • @titan99_ sagte in Verzeichnisnamen für Programmbibliotheken in Projekten:

    @hustbaer Im Moment tendiere ich zu ext als Abkürzung für external, dann hat es gleich viel Buchstaben wie src.

    Bei mir heissen diese Unterverzeichnisse mittlerweile auch external, oder meinentwegen auch ext, wenn mans so kurz mag.

    third-party hatte ich auch mal, bis da dann irgendwann auch mal eigene, externe Projekte drin waren, die nicht wirklich von einer "dritten Partei" stammten.

    Und dependencies habe ich ja ausgeführt. Erstens sind vielleicht nicht alle externen Projekte auch tatsächlich "Abhängigkeiten" und zweitens sind eventuell auch nicht alle Abhängigkeiten in diesem Unterverzeichnis zu finden, wenn man bei einem Projekt z.B. zwischen "internen" und "externen" Abhängigkeiten unterscheidet 😉


Anmelden zum Antworten