2 (oder mehr) projekte ...

[microdigi]

...in eine einzige directory unterbringen?
(wie) geht das evtl bei kde/qt ?
ich sehe nur, dass jedes projekt eine eigene directory structur aufbaut,
damit ist das thema eigentlich erschoepft.

mir geht es aber darum,
einige dateien/module/headers,...
aus einem bestehenden projekt bei einem anderen mit einzubinden.
ich meine, es geht; aber es ist eine 'kruecke',
indem ich stets den kompletten 'original'-pfad bei #include mit eingebe.
aber es fehlen halt noch einige *.cpp files, die ich auch gern im
gemeinsamen zugriff benutzen wuerde.
gut, die standard main kann man ja separat in der (zweiten) gegebenen
dateibaum-struktur unterbringen, aber alle anderen dateien
aus dem ersteren projekt muessten doch eigentlich beliebig zugaengig sein.
nur wie binde ich sie dann in das zweite projekt ein?

danke fuer 'n kurzen hinweis.
ich denke, es wird wieder anda_ska treffen.
fast moechte ich wetten...
:)

[anda_skoa]

Original geschrieben von microdigi

ich denke, es wird wieder anda_ska treffen.
fast moechte ich wetten...
:)

Argl, ich bin so durchschaubar ;)

Eine Möglichkeit wäre eine gemeinsame Library.

Eine andere Möglichkeit wäre, einfach das entsprechende Unetrverzeichnis des einen Projekts in das Verzeichnis des anderen rein zu linken.

Ciao,
_

[microdigi]

naja, anda_skoa, wenn du auch auf dem pc sitzt....:)

ein hauptverzeichnis, dann unterverzeichnis(se) fuer jedes projekt eines.
ja, so hab ich es (natuerlich) gemacht.
nur da gibts halt den schoenheitsfehler, dass
man nicht so einfach die #include einsetzen kann.
das braucht dann den kompletten pfad.
und im managerfenster (links mit den dateien) taucht
das zeug auch nicht auf.
es ist 'etwas unhandlicher' als man es sich so auf anhieb vorstellt...

aber ich werde damit sicher leben.

gruss - und angenehmes jahr (und die anderen danach auch)
wuenscht dir - digi (auf rente harrend :D)

[anda_skoa]

Original geschrieben von microdigi
ein hauptverzeichnis, dann unterverzeichnis(se) fuer jedes projekt eines.


Ich dachte eher an ein Hauptverzeichnis pro Projekt und Unterverzeichnisse für die gemeinsamen Sachen.
In einem der beiden Projekte ist das Unterverzeichnis echt, im anderen nur ein symlink.



nur da gibts halt den schoenheitsfehler, dass
man nicht so einfach die #include einsetzen kann.
das braucht dann den kompletten pfad.


Das kann man auch umgehen, wenn man das Verzeichnis bei den Compiler Optionen mit einer -I Direktive angibt.
Dann findet er den Header auch, wenn nur "name.h" steht.

Ciao,
_

[microdigi]

das mit sem symblischen link habe ich mitterweile auch gemacht.
und dann kann man den namen mit dem symlink vorweg angeben.
das funktioniert sogar :)
im gegensatz zu manchem was bei manchem (r) nicht funktioniert :mad:

ich probier's halt auch noch mal mit der -l option,
und melde mich dann nochmal mit dem ergebnis.

gruss - digi

[microdigi]

hab ich doch einen symbolischen link auf die dateien angelegt,
die ich in beiden projekten gemeinsam nutzen wollte.
ich konnte auch die dateien ins jeweilige (hier in das zweite) projekt
einbinden unter dem neuen link. das ging alles ganz gut.
hinweis: um die dateien uebergreifend anziehen zu koennen,
MUESSEN sie in einer der projekt-umgebungen zugaengig sein.

nur der 'config' macht mir immer wieder in die symbolische directory
einen neuen Makefile und das ganze gelumpe dazu.
der anschliessende compile geht natuerlich so in die hose.

wie kann ich diesen verdammichten automatismus unterbinden?
natuerlich soll ich die shared dateien nur einmal auf der karre haben,
sie aber von beiden projekten aus anziehen koennen.
wenn eine der shared dateien geaendert wird, MUSS sich das
auf BEIDE projekte auswirken.
es geht dabei um zwei unterschiedliche und unabhaengige programme,
die aber bspw die dateistrukturen und diverse verschluesselungsroutinen
sowohl beim ver- als auch beim ent-schluesseln natuerlich gleichartig
ausfuehren muessen. sonst kann es 'unstimmigkeiten' geben,
wenn ich mit dem ersten satz der dateien verschluessele,
und mit einem anderen (evtl kopierten) satz spaeter entschluessele.
das geht mit sicherheit naemlich irgendwann in die hose.

hat einer (anda_skoa?) ne idee wie man dies loesen kann?
demjenigen/derjenigen wird mein dank wohl ewig hinterherschleichen.

gruss - digi
der jetzt vorlaeufig mit zwei source-saetzen arbeitet,
aber ganz genau weiss, dass das im chaos enden wird.


ps: die l- option geht fuer Libraries - und das sind keine libs.






das mit sem symblischen link habe ich mitterweile auch gemacht.
und dann kann man den namen mit dem symlink vorweg angeben.
das funktioniert sogar
im gegensatz zu manchem was bei manchem (r) nicht funktioniert

ich probier's halt auch noch mal mit der -l option,
und melde mich dann nochmal mit dem ergebnis.

[microdigi]

hier fuer die gemeinde das ergebnis;
denn man kann eine solche sache ja nicht gut im raum stehen lassen...

man darf NICHT eine komplette directory mit einem symblischen link auf
das andere project anlegen !
die benoetigten DATEIEN
kann man aber durchaus (auch kreuzweise) symbolisch verlinken.
und dann klappts hervorragend.

damit scheint auch das problem mit dem 'nicht laufenden debugger'
(blaue / rote breakpoints) geloest.

gruss - digi