Hi Christian, Am Thu, 14 Apr 2005 23:30:20 +0200, schrieb Christian Lohmaier: > Hi Eric, > > On Thu, Apr 14, 2005 at 10:16:00PM +0200, Eric Hoch wrote: >> Am Thu, 14 Apr 2005 21:23:51 +0200, schrieb Christian Lohmaier: >>> On Thu, Apr 14, 2005 at 08:43:32PM +0200, Eric Hoch wrote: >> [...] >>> "patch -p0 <path to the patch>" ist mehrdeutig. Es muß vermulich heißen: >>> "patch -p0 < /path/to/patch" wenn man patch nicht von stdin lesen läßt, >> >> genau das ist gemeint. Wobei ich hier merke, daß ich aufführen >> sollte, wie man von stdin lesen läßt und wie nicht. Hast du ne gute >> Idee? > > Bei der bash (vermutlich bei allen shells) geht das z.B. mit "<" > Genauer: > ,---- > | Redirecting Input > | Redirection of input causes the file whose name results from the expan- > | sion of word to be opened for reading on file descriptor n, or the > | standard input (file descriptor 0) if n is not specified. > | > | The general format for redirecting input is: > | [n]<word > `---- > > Als Alternative kann man "cat file | patch ..." verwenden oder auch > "patch -p0 /pfad/zum/spec" und dann den Patch abtippen (und mit <ctrl>+d > die Eingabe beenden) :-)) > > Mein Vorschlag hat nicht nur das Ersetzen der Leerzeichen durch / > beinhaltet, sondern: Weg mit den Klammern als Markierung für den > Dateinamen. Die Zeichen "<" und ">" sind Umleitungswerkzeuge mit denen > die "file descriptors" umgeleitet werden. (STDIN, STDOUT, STDERR, und > selbst definierte)
Stimmt. Ich erinnere mich. Fällt einem gar nicht auf wenn man mit der Materie so vertraut ist. Betriebsblindheit nennt man das. > patch -p0 < /path/to/spec > ^ Das hat hier eine Funktion und ist absichtlich dringeblieben > > patch -p0 <path to spec> > ^ ^ die hier sind mißverständlich >>> Sonstige Anmerkungen: >>> ccache kann bei wiederholten builds erheblich Zeit sparen (weiß nicht ob >>> Du das auf dem Mac schon ausprobiert hast) >> >> Mit m92 das erste Mal, aber ich hab noch nicht ganz raus, wie es >> funktioniert. Daher will ich das erst in einem späteren Update, >> wenn ich selbst weiß, wie es genau geht, aufnehmen. >> >> Ich hab da bisher nicht soviel gemerkt, daß es schneller geht. > Wenn ich mir richtig erinnere: 9 Stunden anstatt 16 Stunden > Kompilierzeit. > >> Aber >> ich denke mal ich hab mich noch nicht intensiv damit >> auseinandersetzen können. > > Das tolle ist ja daß man nur die Links setzen muß und sonst nix :-) Links setzen? Es ist wohl schon zu spät und ich sitz auf dem Schlauch. > Die Funktionsweise: ccache schaut nach "Habe ich das schonmal > kompiliert?" Wenn ja -> nimm das Ergebnis aus dem Cache, compiliere > nicht neu => spar die Zeit. > Wenn nein -> schmeiß den Kompiler an (=> dauert) und speichere das > Ergebnis im cache > Wenn Du debug-builds erstellst solltest Du den cache auf readonly setzen > beziehungsweise den Cache vergrößern (die 1GB standardgröße reichen für > einen Debug bild bei weitem nicht, sprich da wird dann jedesmal neu > kompiliert weil die zwischengespeicherten Ergebnisse immer wieder durch > neue Dateien ersetzt werden müssen weil der Platz nicht reicht. Nee, Debug Builds hab ich noch nicht gemacht. Die nutzen mir als Programmierer DAU auch eher wenig. >>> Wenn bei Mac OS X "lndir" dabei ist, ist ein shadow-tree eine >>> Festplattenplatz sparende Alternative zu einer Kopie der Sourcen. >> >> Cool. Es ist dabei. Wie nutze ich den Befehl? > > $ mkdir shadow > $ cd shadow > $ lndir /pfad/zu/sourcen > > Dann schau nach wie sich dein "patch" verhält. Wenn ich bei mir den > Schadowtree patche, dann wird eine neue Datei angelegt die den Link > ersetzt. Es kann sein daß Dein patch dem Symlink folgt und die > Originaldatei ändert. Werd ich mit dem nächsten m95 wenn die Java patches von Eric Bachard drin sind mal testen und wenn es klappt dann ändere ich die Buildinstructions ab. Man lernt bei OOo nie aus und bisher hab ich das einfach so gemacht mit dem kopieren, weil das für mich damals die schnellste Lösung war die Sourcen "sauber" zu halten und nicht ab und an festzustellen, daß jetzt im cvs ne neue Datei ist. >>> Ansonsten schaut das ziemlich gut aus. >> >>>> Ein paar zusätzlilche Informationen hab ich auch online gestellt. >>>> >>>> Bitte testet auch die Verlinkung von >>>> <http:porting.openoffice.org/mac> ausgehend. >>> >>> Build Instructions (how to get the code) >>> ^and >> >> Ach so du meinst, dass sollte ich noch ergänzen? > > Genau. Aber ich meinte nicht den Link oben, sondern den am Ende der > Seite. Der verweist auf [Viele Kleinigkeiten die ich morgen ändern werde.] Gute Nacht, Eric Hoch der heute genug HTML für die gesammte nächste Woche und bis Ende des Monats gesehen hat. -- ## Ansprechpartner Anwenderunterstützung, users-Mailingliste, MacOSX ## de.OpenOffice.org - Office für MacOS X, Linux, Solaris & Windows ## Openoffice.org - ich steck mit drin! --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
