Ich führe für mich und vereinzelt auch für Kundenprojekte eine Liste von Files, in der alle HDL-Quellen gelistet sind - nach Projekt, SW-Version, HW-Version, etc aufgeteilt. Das wird allerdings größer und immer unübersichtlicher, daher wurde das zwischenzeitlich in eine einfach Access-DB überführt. Ich überlege nun, das zu einem Projekt zu machen. Eine alte Datenbank, die ich seinerzeit mal für C-Code gemacht hatte, soll dafür verwendet werden. Sie müsste allerdings umgebaut werden, weil sie für VHDL, deren Strukturen und Code-Vernetzung nicht 100% taugt. Ich überlege nun, die zu nehmen, eine VHDL-Erweiterung zu machen und somit auch C-Sourcen verwalten zu können. Z.B. soll man diese linken zu können, damit man System-C und andere Quellen, z.B. für Zynq, damit verwalten kann. Man könnte dann ein Projekt definieren und versionieren, alle Sourcen zuordnen und hätte eine einfache Möglichkeit, die Stände und Versioen zu verwalten und sich jederzeit eine Übersicht geben zu lassen, welche Source-Version jeweils benötigt wird. Jede Source hat link-Möglichkeiten auf eine Ursprungsquelle, von der sie gfs abgeleitet wurde. Damit hat man mit einem Klick alle Derivate und Projekte in einer Liste, in der die Source oder ihre Kinder verwendet wurden. Damit gibt es sofort auch eine Übersicht über verwendete header und functions und kann sehen, ob es da Inkonsistenzen gibt, welche Verzeigerungen gfs fürs das neue Projekt falsch sind und vor allem auch, welche files veraltet sind und nicht mehr benötigt werden. Jede Source ist charakterisierbar, d.h. maturity, Entwicklungs- und Teststatus sind ersichtlich. Die DB würde ich dann allen zugänglich machen und wäre für private Nutzung kostenlos. Angedacht ist ein Frontend-Back-End-System, sodass man einfach die GUI, Abfragen und Berichte im Fall von Erweiterungen und Verbesserungen austauschen kann. Hätte jemand Interesse, daran mitzuwirken und Input zu geben, was benötigt wird?
:
Verschoben durch Moderator
Das klingt für mich nach so eine Art 'Opencores' nur mit mehr Vernetzung zwischen den Teilprojekten. Bzw. eine Funktionalität, wie sie svn-externals bietet. Klingt auf jeden Fall interessant, aber auch nach relativ hohem initialen Aufwand. Ich glaube dafür überschneiden sich bei mir die Projekte nicht ausreichend genug. Duke
Ich wuerde eher eine Infrastruktur nehmen die es schon gibt. Z.B. Python PiP oder PHP Composer. Wobei ich eher zu PiP tendieren wuerde.
:
Bearbeitet durch User
Kann man eigentlich seine eigenen Komponenten z. B. bei Vivado in den IP Katalog einpflegen? Oder muss das von Xilinx geschehen? Das wäre ja doch recht schick. Ich stelle mir das so vor, dass man sich an eine Ordnerstruktur von Xilinx halten muss und dann noch eine Datei für den Wizard anlegt nach einem Standard. Aber dann gibt man einem neu installieren Vivado einfach einen Pfad und alle eigenen IPs tauchen auf.
:
Bearbeitet durch User
Gustl B. schrieb: > Kann man eigentlich seine eigenen Komponenten z. B. bei Vivado in den IP > Katalog einpflegen? Oder muss das von Xilinx geschehen? Das wäre ja doch > recht schick. Ja, man kann in jedem Projekt Pfade zu zusätzlichen IP-Repositories hinzufügen. Dies geht sowohl über den IP Integrator als auch per "set_property ip_repo_paths". Ich bin nicht unbedingt ein so großer Freund von IP-Respositories, da es zwei wesentliche Einschränkungen gibt: - keine Unterstützung von VHDL 2008 in IP-Blöcken - umständliches Entpacken/Packen von in der Weiterentwicklung befindlichen IP-Blöcken Grundsätzlich ist es zwar eine nette Idee, dass auch Firmware-Treiber in IP-Blöcken enthalten sein können, aber während der Entwicklung solch eines Treibers ist es unglaublich lästig, einen Umweg über den IP Packager machen zu müssen. So etwas eignet sich nur für wirklich "fertige" Treiber, d.h. für IP-Blöcke, die man explizit an Dritte liefert. Für den Eigenbedarf ist das häufig eher nur umständlich. In vielen Fällen bevorzuge ich es daher, externe VHDL-Quellen als sog. "HDL Module" im Vivado-Blockdesign hinzuzufügen. Dies geht auch ganz ausgezeichnet mit AXI-Peripherieblöcken, die man mit Hilfe des entsprechenden Wizards angelegt hat und die auch völlig korrekt in der AXI-Adresstabellle auftreten und mittels HSI an das zugehörige SDK-Projekt gemeldet werden. Ich kann mir vorstellen, dass Jürgen S. auch derartige Quellen meint.
Moin, ich wuerde beim heutigen Wissenstand arg dazu tendieren, gitlab minimal aufzubohren. Sprich: git ist die Datenbank. Bloss nicht sowas neu machen (been there..), was fuer Software schon lange tut, geht auch fuer HW. Die Wartung einer manuell gefuellten Datenbank wird schnell mal zur immensen Arbeit, wenn man Aenderungen vornimmt, die sich irgendwie propagieren. Das erledigt man besser mit einer kontinuierlichen Integration fuer alle abgedeckten Konfigurationen (oder spezifische Projekte). Da gibt es eine Menge unterschiedlicher Strategien, diese Konfigurationen zu beschreiben (kconfig, XML, [Strict]YAML, ...). Das laesst sich nicht so einfach/elegant in einer tabellarischen Datenbank abbilden. Was es allerdings m.W. so noch nicht gibt: eine GUI, bei der man sich eben mal die verschiedenen Testszenarien schnell zusammenklicken koennte, wie: Bau mir mal eben board supply 'knorpelpeter' mit IP cores aus LibMurks mit Branches 'test', 'master', 'v0.1' plus Firmware 'unstable' und spuck mir PASS/FAIL aus. Und bei Klick den ganzen Test-Report. Und das erst mal im 'dry-run', ohne gleich einen Commit machen zu muessen. Wenn das das geht, bekommt das Ding einen 'working' tag und wird automatisch gepusht (inkl. nachgefuehrte Abhaengigkeiten von den entsprechenden Versionen in den git-submodulen). Die PASS/FAIL-Matrix (was mit was laeuft) koennte natuerlich in eine Datenbank um daraus Web-Reports zu generieren. Was sonst VHDL-Source-Analyse, DRC und korrekte Aufloesung der Interfaces angeht, kann man mit GHDL/XML viel machen. Laesst sich auch gut in gitlab-Pipelines integrieren.
:
Bearbeitet durch User
Martin S. schrieb: > Was es allerdings m.W. so noch nicht gibt: > eine GUI, bei der man sich eben mal die verschiedenen Testszenarien > schnell zusammenklicken koennte, wie: > Bau mir mal eben board supply 'knorpelpeter' mit IP cores aus LibMurks > mit Branches 'test', 'master', 'v0.1' plus Firmware 'unstable' und spuck > mir PASS/FAIL aus. Und bei Klick den ganzen Test-Report. > Und das erst mal im 'dry-run', ohne gleich einen Commit machen zu > muessen. 10 PRINT "FAIL" Das war einfach! SCNR
Danke schon einmal für die bisherigen Antworten. Ich kenne natürlich die tools für die Versionsverwaltung und auch deren Möglichkeiten. Diese decken aber nach meiner Kenntnis nicht die Möglichkeiten ab, die ich anstrebe. Was man natürlich andenken könnte, wäre eine Art Anbindung. Z.B. könnte man SVN-tags extrahieren und hinterlegen, katalogisieren und suchbar machen.
Jürgen S. schrieb: > Z.B. könnte man SVN-tags extrahieren und hinterlegen, katalogisieren und > suchbar machen. Das ist genau das was du mit PiP oder Composer erreichst, nur eben auf Basis von Git (SVN koennte auch unetrstuetzt sein, habe ich noch nie probiert). Eine einfacherer Moeglichkeit (die allerdings mehr Handarbeit erfordert) waere mit Git Submodules zu arbeiten.
Git ist nur für Textdateien sinnvoll und ein Versionierungssystem, keine Datenbank. Wenn der Datenbestand bisher sinnvoll in Access gepflegt werden kann, dann wäre eine relationale Datenbank vielleicht sinnvoll. Meine Empfehlung wäre SQLite, weil man das wunderbar in eigene Programme einbinden kann und keine nennenswerten Abhängigkeiten hat. Wenn das ein Web-Dienst werden soll, lässt sich das SQL (wenn man aufpasst) auch einfach migrieren. Soweit ich das einschätzen kann, geht es hier nicht darum, eine Versionsmatrix zu versionieren, sondern um einen aktuellen Stand zu pflegen.
Aber genau den Sinn dieser Datenbank verstehe ich nicht. Man hat ein VHDL Projekt, welches andere Projekte als Abhaengigkeiten hat. Diese Abhaengigkeiten wuerde man jetzt z.B. via PiP in die requirements.txt schreiben (welche Projekt in welcher Versionsnummer soll eingebunden werden). Die Datenbank wuerde dann Sinn machen, wenn man z.B. Metriken erstellen moechte welches Projekt wie oft eingebunden wurde oder ob ein veralteter Versionsstand vorliegt. Wenn ich es aber richtig verstanden habe geht es aber nicht darum Projekte zu analysieren sondern aufzusetzen.
S. R. schrieb: > Git ist nur für Textdateien sinnvoll und ein Versionierungssystem, keine > Datenbank. Wenn der Datenbestand bisher sinnvoll in Access gepflegt > werden kann, dann wäre eine relationale Datenbank vielleicht sinnvoll. > Hinter git steckt genau die Objekt-Datenbank, die man's fuer's Tracken und fuer diese ganzen Operationen der Versionifizierung, Abhaengigkeiten usw. braucht ('git, the stupid content tracker'). Und natuerlich kann man das auch fuer Binaerdateien nutzen. Nur textbasiertes 'diff' macht dann nur bedingt Sinn (dafuer gibt's Plugins). Ich checke z.b. auch mal PDFs ein, die werden dann halt durch diffpdf gekloppt. > Meine Empfehlung wäre SQLite, weil man das wunderbar in eigene Programme > einbinden kann und keine nennenswerten Abhängigkeiten hat. Wenn das ein > Web-Dienst werden soll, lässt sich das SQL (wenn man aufpasst) auch > einfach migrieren. > SQLite wirft einfach irgendwann den Bettel hin, wenn man einen riesigen Baum verwalten muss, wie z.b. ein Linux-BSP mit verschiedenen Branches gegen div. Hardware-Konfigurationen. Bei meinem Versuch damals war das irgendwann nicht mehr skalierbar/anwendbar. SVN sollte man fuer sowas erst gar nicht anfangen zu verwenden. Da gibt es schon fundamentale Probleme mit externals und die Branchverwaltung ist auch nicht skalierbar. Git ist einfach auch fuerchterlich schnell, was sich in der CI bei n * m Komplexitaet bemerkbar macht. Tobias B. schrieb: > Eine einfacherer Moeglichkeit (die allerdings mehr Handarbeit erfordert) > waere mit Git Submodules zu arbeiten. Genau das ist eigentlich Stand der Methodik. Das sollte man nicht mehr neu erfinden. Hoechstens Tools druebersetzen, die das Management fuer 'lazy developers' leichter machen. git ist als Lowlevel-Tool zwar fuer den Anwender eine echte Sau, weil's oft auch zuviele Wege zum Ziel gibt. Aber es gibt halt so gut wie nichts, was damit nicht geht.
Martin S. schrieb: > Genau das ist eigentlich Stand der Methodik. Das sollte man nicht mehr > neu erfinden. Hoechstens Tools druebersetzen, die das Management fuer > 'lazy developers' leichter machen. git ist als Lowlevel-Tool zwar fuer > den Anwender eine echte Sau, weil's oft auch zuviele Wege zum Ziel gibt. > Aber es gibt halt so gut wie nichts, was damit nicht geht. Das einzigste was mich bei den Submodules nervt (was allerdings nicht an Git liegt), ist, dass man relative Pfade braucht wenn das korrekt mit Gitlab zusammenarbeiten soll. Daher muss man immer die .gitmodules von Hand anfassen. [1] Gibt es da evtl. einen eleganteren Weg, z.B. eine Git Config damit Git automatisch die absoluten Pfade relativ macht? [1] https://docs.gitlab.com/ee/ci/git_submodules.html
Ich nutze aus Prinzip nur relative Pfade, wenn multi-user. Man kann mit
pre-commit hooks dreckige Sachen machen, aber wenn du lokal absolute und
'upstream' relative Pfade unterhalten willst, wuerde ich das per branch
machen ('local' branch enthaelt nutzerspezifische Pfade und
Cfg-Dateien). Dann hast du halt bisschen Merge-gezuppel.
Oder symbolischen Link innerhalb des relativen Unterverzeichnis des
submodule zum absoluten setzen. Das ist dann halt bisschen gefaehrlich,
wenn man lokal ne Pipeline aufsetzt, bei der unterschiedliche
Entwicklungszweige bauen, die wiederum von unterschiedlichen
submodul-Zweigen abhaengig sind, aber dann auf das gleiche Verzeichnis
zeigen..
Tobias B. schrieb: > Das einzigste was mich bei den Submodules nervt (was allerdings nicht an > Git liegt), ist, dass man relative Pfade braucht wenn das korrekt mit > Gitlab zusammenarbeiten soll. Daher muss man immer die .gitmodules von > Hand anfassen. [1] > [1] https://docs.gitlab.com/ee/ci/git_submodules.html Martin S. schrieb: > Ich nutze aus Prinzip nur relative Pfade, wenn multi-user. Man kann mit > pre-commit hooks dreckige Sachen machen, aber wenn du lokal absolute und > 'upstream' relative Pfade unterhalten willst, Martin, schau dir mal den gitlab doku link an. Hier geht es nicht um absolute/relative Pfade sondern um absolute/relative URLs. Habe dabei auch etwas neues gelernt, danke. Ist noch nicht aktuell aber Gitlab CI steht bei uns auf dem TODO. Tobias B. schrieb: > Die Datenbank wuerde dann Sinn machen, wenn man z.B. Metriken erstellen > moechte welches Projekt wie oft eingebunden wurde oder ob ein veralteter > Versionsstand vorliegt. Da wir eh schon Gitlab haben, wäre es super wenn wir diese Information gleich da drin bekommen würden. Gibt es leider nicht, wünschen sich aber andere auch: https://gitlab.com/gitlab-org/gitlab/issues/21719
Christoph Z. schrieb: > Martin, schau dir mal den gitlab doku link an. Hier geht es nicht um > absolute/relative Pfade sondern um absolute/relative URLs. Genau, vielen Dank. Da hab ich mich echt schlecht ausgedrueckt. :-( Christoph Z. schrieb: > Habe dabei auch etwas neues gelernt, danke. Ist noch nicht aktuell aber > Gitlab CI steht bei uns auf dem TODO. Falls du ein CI Beispiel brauchst mit VHDL und Python Support, kannst mal hier reinschauen: https://gitlab.com/Elpra/drever-framework/drever Christoph Z. schrieb: > Da wir eh schon Gitlab haben, wäre es super wenn wir diese Information > gleich da drin bekommen würden. Gibt es leider nicht, wünschen sich aber > andere auch: https://gitlab.com/gitlab-org/gitlab/issues/21719 Danke fuer den Link, hab gleich mal ein Up-Vote dagelassen. Ich schaetze bis das implementiert ist dauert es ewig bis nie. Wahrscheinlich muss man da fast selbst ran und entsprechend nenn MR absetzen um zu Lebzeiten noch etwas von dem Feature zu haben. :-(
:
Bearbeitet durch User
Christoph Z. schrieb: > Martin, schau dir mal den gitlab doku link an. Hier geht es nicht um > absolute/relative Pfade sondern um absolute/relative URLs. Wenn ich das jetzt richtig ueberflogen habe, geht's darum um den checkout vor dem Start des Containers/runners. Ich checke da nur ein Minimum fuer die build-Umgebung aus und ziehe mir dann der Rest im laufenden Container, da natuerlich mit absoluten URLs oder wenn konfig-Option per Environment-Variable.
Ich meine auch Gitlab selbst braucht relative URLs damit die Verlinkungen zu den Submodule Repositories innerhalb einer Gitlab Instanz entsprechend funktionieren. Martin S. schrieb: > Ich checke da nur ein > Minimum fuer die build-Umgebung aus und ziehe mir dann der Rest im > laufenden Container, da natuerlich mit absoluten URLs oder wenn > konfig-Option per Environment-Variable. Hat entsprechend den Nachteil, dass dein Container auch Git Unterstuetzung braucht. Relativ viele, vorallem minimalistische Docker Images, haben aber kein Git mit dabei. Entsprechend musst du dann jedesmal Git on-the-fly installieren oder ein Image warten, dass Git Unterstuetzung hat. Beides jetzt kein Hexenwerk, aber unnoetige Arbeit ist es halt trotzdem.
:
Bearbeitet durch User
Tobias B. schrieb: > Beides jetzt kein Hexenwerk, aber unnoetige Arbeit ist es halt trotzdem. Ein einmaliges > apt-get install git im Dockerfile? Meine CI-Strategie ist grundsaetzlich, das System in der Umgebung 'from scratch' zu bauen/testen, in der es auch eingesetzt wird, gerade wenn Abhaengigkeiten von verschiedenen Tools/Repos vorliegen. Minimalistisch ist dabei eh kein Kriterium mehr.
Martin S. schrieb: > Ein einmaliges >> apt-get install git > im Dockerfile? Verwendest du wirklich ein eigenes Dockerfile pro Projekt und baust dir deinen Container immer aufs neue von vorne? Sinnvoller waere es die Images fuer Unit-Tests und Firmware Builds separat zu pflegen. Und genau diese Pflege kann man sich in manchen Faelle halt sparen wenn man ein fertiges Image auf Dockerhub findet und eben nicht jedes dieser Images hat Git Support. Von daher bleiben dir genau 3 Moeglichkeiten: 1.) Bei jedem Run Git im neu aufgespannten Container installieren. 2.) Ein Image Repo Pflegen (Git via Dockerfile installieren, Image bauen und ins Repo einpflegen - Vorgang wiederholen bei Updates vom Parent Image oder auch dafuer einen Build Prozess aufbauen) 3.) Den Git Support von Gitlab nutzen Punkt 2 macht regelmaessig Arbeit, Punkt 1 braucht entsprechend Server Kapazitaeten und skaliert entsprechend schlecht mit der Anzahl von Commits / Usern. Kleiner Nachtrag: Punkt 2 ist fuer FPGA Projekte natuerlich deutlich weniger Aufwand, die die Software Abhaengigkeiten entsprechend gering sind und auch nicht wahnsinns schnelllebig was Updates betrifft.
:
Bearbeitet durch User
@Tobias: > > Verwendest du wirklich ein eigenes Dockerfile pro Projekt und baust dir > deinen Container immer aufs neue von vorne? > Nicht zwingend pro Projekt, aber das Mutter-Image ist in einer gewissen Pipeline Teil der CI. > Sinnvoller waere es die Images fuer Unit-Tests und Firmware Builds > separat zu pflegen. Und genau diese Pflege kann man sich in manchen > Faelle halt sparen wenn man ein fertiges Image auf Dockerhub findet und > eben nicht jedes dieser Images hat Git Support. > Wuerde jetzt etwas zu ausfuehrlich - in Kuerze: Der Builder baut sich selbst und testet sich auch selbst. Sonst haette ich mehr Management-Overhead. Ich setze natuerlich auf einem Standard OS auf, da muessen sowieso ein paar Tools installiert werden. Ob da jetzt noch git zukommt... Der Knackpunkt ist aber, dass einige Submodule auf eine 'selektive' Weise eingebunden werden. Da moechte ich nicht mit gitlab rumfummeln, das kann das Buildsystem (im Container) besser. > Von daher bleiben dir genau 3 Moeglichkeiten: > > 1.) Bei jedem Run Git im neu aufgespannten Container installieren. > 2.) Ein Image Repo Pflegen (Git via Dockerfile installieren, Image bauen > und ins Repo einpflegen - Vorgang wiederholen bei Updates vom Parent > Image oder auch dafuer einen Build Prozess aufbauen) > 3.) Den Git Support von Gitlab nutzen > > Punkt 2 macht regelmaessig Arbeit, Punkt 1 braucht entsprechend Server > Kapazitaeten und skaliert entsprechend schlecht mit der Anzahl von > Commits / Usern. > Nicht so kompliziert... Die Arbeit bei 2), wenn Paket-Updates noetig (die seltener releast werden), geht gegen Null..ist ja Teil der CI. Der Container mit aller SW wird nur (auto-)gepusht, wenn der Regresstest durchlaeuft. > Kleiner Nachtrag: Punkt 2 ist fuer FPGA Projekte natuerlich deutlich > weniger Aufwand, die die Software Abhaengigkeiten entsprechend gering > sind und auch nicht wahnsinns schnelllebig was Updates betrifft. Gerade wegen der SW-Abhaengigkeiten nutze ich Methode 2, wenn irgendwo was schepplaeuft, sieht man das dann relativ zeitnah im "Badge Cockpit". Das einzige 'Problem' bei submodule-Abhaengigkeiten ist, dass SM von Drittparteien bei Aenderungen die CI nicht unmittelbar triggern, sondern man das mit einem Hack (crontab checkt nach Aenderungen) selber ausloesen muss.
@Martin Ok, dan ist da wirklich nichts Ungewoehnliches dabei, ausser dass eben der Checkout Prozess komplett manuel gehandelt wird (und auch eben innerhalb des Containers anstatt dass es als Cache gemountet wird). Ist halt der Trade-Off zwischen Funktionalitaet und Komfort. Ohne extra Arbeit geht es in deinem Workflow sicher nicht, anderseits bist du halt auch flexibler. So richtig den Vorteil sehe ich allerdings noch nicht, kann mir aber schon vorstellen, dass das ind einem speziellen Fall seine Gruende hat. Etwas strange ist es trotzdem, zumal Gitlab eben Submodules unterstuetzt und die Unterstuetzung mit der Zeit sicher Nutzerfreundlicher wird, statt schlechter. Mark W. schrieb: > Die Jungs aus Draeschdn machen da auch schon was: > > https://github.com/VLSI-EDA/PoC Das ist aber eher eine Sammlung von Design Patterns, als ein Management Tool fuer IPs oder?
Tobias B. schrieb: > Mark W. schrieb: >> Die Jungs aus Draeschdn machen da auch schon was: >> >> https://github.com/VLSI-EDA/PoC > > Das ist aber eher eine Sammlung von Design Patterns, als ein Management > Tool fuer IPs oder? Ja, ich dachte dass es fuer die Leute hier interessant ist, da ich es gerade beim Suchen entdeckt hatte und mich an diesen Thread erinnerte. Ich dachte es ging um eine Datenbank fuer Code Vorlagen. Ich habe es ganz einfach als Text in einem Ordner, einfacher geht es nicht. P.S.: Manchmal bediene ich mich auch heimlich bei Lothar auf seiner Webseite. :-)
Tobias B. schrieb: > Etwas strange ist es trotzdem, zumal Gitlab eben Submodules > unterstuetzt und die Unterstuetzung mit der Zeit sicher > Nutzerfreundlicher wird, statt schlechter. Oder anders: stell dir ein Build-System a la buildroot fuer Embedded-Systeme fuer Hardware vor. Je nach Kconfig-Option wird per git, svn, etc. (nur) gezogen, was gebraucht wird, allenfalls auf eine spezifische Revision festgezurrt (ev. mit Patch). Heisst, eine groessere Anzahl (~50) 'defconfig_platform-variant'-Dateien gibt die Konfigurationen vor. Das steckt alles bereits im Container, selbiges auf gitlab-ci umzufrickeln waere eine fehleranfaellig YML-Orgie. Da halte ich die kconfig-Tools fuer stabiler. Oder: Running legacy no touchy! Besagter Container (namens 'masocist') laesst sich auch in der OpenSource inspizieren, gibt dazu auch ein Beispiel mit RISC-V in der CI (oder im Browser): https://section5.ch/index.php/2019/10/24/risc-v-in-the-loop/ Vielleicht sollten wir aber fuer die ganze CI-Diskussion doch nen anderen Thread auftun.
Martin S. schrieb: > Besagter Container (namens 'masocist') laesst sich auch in der > OpenSource inspizieren, gibt dazu auch ein Beispiel mit RISC-V in der CI > (oder im Browser): > > https://section5.ch/index.php/2019/10/24/risc-v-in-the-loop/ Ok, alles klar. Werde ich mir mal ansehen. Ich verstehe jetzt auch den Workflow schonmal deutlich besser. Hier gehts weit ueber ein paar VHDL Sourcen hinaus. :-) Martin S. schrieb: > Vielleicht sollten wir aber fuer die ganze CI-Diskussion doch nen > anderen Thread auftun. Ja, das macht Sinn. :-)
Kleine Info: Python Poetry ist in der Version 1.0 erschienen https://www.heise.de/developer/meldung/Python-und-die-Poesie-der-Pakete-Poetry-1-0-hilft-beim-Dependency-Management-4618185.html
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.