Kicad build mit minGW

[Simon H. (simi)]

Salü!

Ich verzweifle gerade dabei, Kicad unter minGW zu builden. Ich ging nach 
dieser Anleitung vor:

http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/view/head:/Documentation/compiling/build-msw.txt


WxWidgets builden und installieren ging problemlos, aber wenn ich 
versuche, KiCad zu builden, bekomme ich folgende Fehlermeldung:

fatal error: wx/html/htmlwin.h: no such file or directory

Ich bin ein bisschen auf Spurensuche gegangen und habe festgestellt, 
dass in FinwxWidgets.cmake wx-config aufgerufen wird, und da bekommt er 
sinnvolle Daten für die Variable wxWidgets_INCLUDE_DIRS und 
wxWidgets_CXX_FLAGS. Letztere Variable beinhaltet denn auch 
sinnvollerweise -I<Pfad zu besagtem htmlwin.h>

Lustigerweise verwirft er weiter unten in FindwxWidgets.cmake all diese 
-I<...> Include-Pfade, und was übrig bleibt, ist: 
wxWidgets_CXX_FLAGS=mthreads. Allerdings muss ich gestehen, dass mir die 
Abhängigkeiten in diesem cmake-Konstrukt noch nicht so richtig klar 
sind.

Hat jemand von Euch eine Idee, was das Problem sein könnte?

Gruäss
Simon

[Simon H. (simi)]

Ohmannomannomannomann!!! Etwa zwei Wochen lang habe ich mich nun damit 
herumgeärgert!

Das Problem war, dass - keine Ahnung warum - cmake ein Problem damit 
hatte, dass MinGW zusammen mit wxWidgets auf der C- und die 
KiCad-Sourcen auf der D-Partition lagen. Nachdem ich die auf die 
C-Partition rübergeschmissen hatte, funktionierte es bestens!

Ich werde gelegenlich mal das KiCad-Team fragen, ob sie wohl in der 
Anleitung darauf hinweisen könnten.

Cool, jetzt kann ich mich mal ganz sachte an mein Vorhaben ranwagen, ich 
möchte nämlich gerne KiCad beibringen, layerspezifische Width- und 
Clearance Constraints anzuwenden. :-)

Gruäss
Simon

[andreas6 (Gast)]

Hallo,

dieses Paket ist nicht wirklich flexibel, was den Installationsort 
angeht. Ich habe das hier auch im Einsatz und es möchte am liebsten auf 
C: in einem Pfad ohne Leerzeichen laufen. C:\Programme ist z.B. 
unkritisch, da tut es problemlos. Leider erwähnt die Anleitung diesen 
Umstand gar nicht.

MfG. Andreas

[Simon H. (simi)]

Sieht so aus. :-)

Funktioniert das bei Euch eigentlich mit dem wxFormBuilder? Mich 
schimpft er jedesmal, wenn ich ein .fbp File von Kicad öffne, aus, ich 
habe das mit einer neueren Version (notabene neuer als das neuste 
verfügbare nightly-build vom Server) von wxFormBuilder gemacht. Und dann 
in Capital letters: "If you save this project, YOU WILL LOSE DATA!"

Und tatsächlich, wenn ich speichere, kann man nicht mehr kompilieren. 
Nicht verwunderlich, zumal der ganz merkwürdige Fragmente ins .h und 
.cpp File schreibt.

Mein Workflow ist jetzt wie folgt:

1. kopiere .h un .cpp des zu verändernden Dialogs unter neuem Namen
2. Öffne das .fbp, editiere es und generiere .h und cpp.
3. Entferne mit Hilfe der Originalfiles und BeyondCompare die Hickups.

Ein bisschen umständlich... :-( Kennt Ihr diese Probleme auch?

Gruäss
Simon

[andreas6 (Gast)]

Hallo,

Dein Weg ist wohl der falsche, denn dieser Code wird generiert. Dort 
fummelt man nicht mehr per Hand drin herum. Schau mal in die 
Mailingliste der Entwickler, da war das auch mal Thema. Dort wurde auch 
erklärt, wie Dialoge anzufassen sind.

MfG. Andreas

[Simon H. (simi)]

andreas6 schrieb:
> Dein Weg ist wohl der falsche, denn dieser Code wird generiert. Dort
> fummelt man nicht mehr per Hand drin herum.

Jaja, ich weiss schon, wie man es machen sollte. Was aber, wenn der 
generierte Code (auszugsweise) so aussieht?

...
#include <wx/textctrl.h>
#include <wx/scrolwin.h>
#include <wx/button.h>
#include <wx/dialog.h>#include <wx/dialog.h>
"1" { #include <wx/aui/aui.h> }

//////////////////////////////////////////////////////////////////////// 
///

#define ID_ADHESFRONTNAME 1000
#define ID_ADHESFRONTCHECKBOX 1001
#define ID_ADHESFRONTCHOICE 1002

...


//////////////////////////////////////////////////////////////////////// 
///////
/// Class DIALOG_LAYERS_SETUP_BASE
//////////////////////////////////////////////////////////////////////// 
///////
class DIALOG_LAYERS_SETUP_BASE : public DIALOG_SHIMpublic DIALOG_SHIM
{
  private:

  protected:


...

    DIALOG_LAYERS_SETUP_BASE( wxWindow* parent, wxWindowID id = 
wxID_ANY, const wxString& title = _("Layer Setup"), const wxPoint& pos = 
wxDefaultPosition, const wxSize& size = wxSize( 643,930 ), long style = 
wxDEFAULT_DIALOG_STYLE|wxRESIZE_BORDER );DIALOG_LAYERS_SETUP_BASE( 
wxWindow* parent, wxWindowID id = wxID_ANY, const wxString& title = 
_("Layer Setup"), const wxPoint& pos = wxDefaultPosition, const wxSize& 
size = wxSize( 643,930 ), long style = 
wxDEFAULT_DIALOG_STYLE|wxRESIZE_BORDER );  "1" { wxAuiManager m_mgr;
    }


Und das File hat insgesamt eine schliessende geschweifte Klammer mehr 
als öffnende.

:-)

Und das, notabene, wenn ich nur ein Dialogfile öffne und unverändert den 
Code generieren lasse.

Das ist kein C++ Code, sondern ein wildes Durcheinander. Irgendwas geht 
da beim Generieren schief.
Und eben dieses Durcheinander muss ich jedesmal nachträglich wieder 
aufräumen.

Aber eben, sooo schlimm ist es nicht. Die Fehler sind sehr lokal, und 
mit Beyond Compare kann man ganz einfach die Stellen, bei denen sich der 
Codegenerator verschluckt hat, ausbügeln. Will heissen: Die Stellen, die 
ich im GUI angepasst/erweitert habe, lasse ich drin, die passen auch, 
und die Stellen, die das Programm falsch generiert hat, ersetze ich 
wieder durch denCode, der früher mal offensichtlich richtig generiert 
wurde. Das heisst, ich schreibe selber keine einzige C++-Zeile.

[Simon H. (simi)]

BTW:
Was haltet Ihr von der Idee? Ich bin gerade dabei, einen Vierlagenprint 
zu designen, und bestellt wird dann bei seeedstudio.

Die haben aber für Aussen- und Innenlagen unterschiedliche Width- und 
Clearance-Constraints. Das unterstützt KiCad nicht (oder ich war zu 
blöd, das Feature zu finden).

Ich habe nun (siehe Attachment) in einer Nachtübung den 
Layerstack-Dialog erweitert. Die Idee dahinter:

Die (netzbasierten) Constraints bleiben, wie sie sind. Zusätzlich kann 
man aber für jede Lage einen Width- und Clearance-Constraint definieren. 
Man muss nicht. Standardeinstellung ist 0mm.

Der DRC und das "Zeichnundshelferlein" nehmen nun jeweils die grössere 
Zahl. Wenn die Einstellungen auf 0 lässt, bleibt also alles beim Alten.

Was meint Ihr dazu?

Gruäss
Simon