macports: Als Apple-Developer registrieren?

Cie

Aktives Mitglied
Thread Starter
Dabei seit
21.02.2014
Beiträge
162
Reaktionspunkte
1
Hallo,

ich würde mir gerne macports installieren, um mir die GNU Coreutils zu installieren, weil ich mit deren Syntax und Funktionsumfang sehr vertraut bin (und für rsnapshot hätte ich gerne GNU cp). Auf der macports-Webseite steht, dass ich zuvor Apples Command Line Developer Tools installieren muss. Diese scheine ich aber nur als Apple Developer zu bekommen. Bei dem Anmelde-Prozess müsste ich falsche Angaben machen, da ich ja kein Entwickler bin. Das widerstrebt mir. Sehe ich das zu eng? Aber wie komme ich dann an die Apple Command Line Developer Tools?

Grüße
Cie
 
Warum musst Du dann falsche Angaben machen? Registrier Dich doch kostenlos als Developer.
 
Die Tools kannst Du so runterladen. Am Developer-Programm teilnehmen (gegen Geld) musst Du nur dann, wenn Du Apps in den Store stellen willst oder aufs eigene iPhone übertragen.
 
Xcode kriegst du doch auch im mac app store kostenlos.
darüber kannst du auch die command line tools haben, aber eine zeitlang brauchte man darin auch für das laden einen ADC account. ändern die aber alle nase lang.
 
darüber kannst du auch die command line tools haben, aber eine zeitlang brauchte man darin auch für das laden einen ADC account. ändern die aber alle nase lang.
Das war früher so, inzwischen muss man sich die CLT als Paket aus dem Downloadbereich des Developer Programs holen, aber die kostenlose Mitgliedschaft reicht nach wie vor aus.

Der TE hätte die Möglichkeit einfach homebrew anstelle von macports zu benutzen. Dieses führt ebenfalls die coreutils, begnügt sich aber mit einem installierten Xcode ohne CLT. Xcode kann, wie bereits genannt, ohne Developer Anmeldung aus dem MAS geladen werden.
 
Warum musst Du dann falsche Angaben machen? Registrier Dich doch kostenlos als Developer.

Weil gefragt wird, was ich entwickele und für welche weiteren Plattformen ich entwickele.
 
Und niemand verlangt, daß sich jemand, der sich dort anmeldet, auch nachweist, daß er tatsächlich aktiv irgendetwas entwickelt.
Es soll sogar Leute geben, eine zahlende Mitgliedschaft eingehen, nur um Betaversionen der neuesten Systeme zu bekommen.
 
Xcode kriegst du doch auch im mac app store kostenlos.
darüber kannst du auch die command line tools haben, aber eine zeitlang brauchte man darin auch für das laden einen ADC account. ändern die aber alle nase lang.

Xcode habe ich auch schon. Wenn ich dort aber auf auf »Open Developer Tool > More Developer Tools« gehe, werde ich auf die Apple-Developer-Seite geleitet. Oder suche ich an der falschen Stelle?
 
Und niemand verlangt, daß sich jemand, der sich dort anmeldet, auch nachweist, daß er tatsächlich aktiv irgendetwas entwickelt.
Es soll sogar Leute geben, eine zahlende Mitgliedschaft eingehen, nur um Betaversionen der neuesten Systeme zu bekommen.

Mit anderen Worten: Ich sehe das zu eng mit den abgefragten Angaben?
 
Weil gefragt wird, was ich entwickele und für welche weiteren Plattformen ich entwickele.

Das interessiert doch keinen weiter, niemand wird dich kontaktieren und ein Demo-Programm zu deinen Fähigkeiten verlangen ;)
 
[…]

Der TE hätte die Möglichkeit einfach homebrew anstelle von macports zu benutzen. Dieses führt ebenfalls die coreutils, begnügt sich aber mit einem installierten Xcode ohne CLT. Xcode kann, wie bereits genannt, ohne Developer Anmeldung aus dem MAS geladen werden.

Auf homebrew war ich auch gestoßen. Wegen eines Beitrags bei StackExchange hatte ich mich für macports entschieden … Tatsächlich weiß ich aber noch so gut wie gar nichts über homebrew und macports.
 
Xcode habe ich auch schon. Wenn ich dort aber auf auf »Open Developer Tool > More Developer Tools« gehe, werde ich auf die Apple-Developer-Seite geleitet. Oder suche ich an der falschen Stelle?

öffne mal das Xcode paket im finder.
rechts bzw control klick und "Paketinhalt zeigen".
dann auf Contents/Developer/usr/bin
wenn dort gcc usw zu finden sind, dann brauchst du nicht mehr.

den pfad kannst dann auch bei macports angeben, falls der das nicht automatisch findet.
 
Auf homebrew war ich auch gestoßen. Wegen eines Beitrags bei StackExchange hatte ich mich für macports entschieden … Tatsächlich weiß ich aber noch so gut wie gar nichts über homebrew und macports.
Hat dich das "g" Prefix abgeschreckt? Die Sache ist die, mit den coreutils "überschreibst"/überdeckst du einige Dinge, die schon auf deinem Rechner drauf sind und von denen explizit die BSD Syntax erwartet wird. Das führt zwangsläufig zu Problemen. Du kannst dir natürlich beispielsweise gnu sed installieren, aber alles was BSD sed erwartet, wird Probleme haben, was ja schon bei den extended Flags -E/-r anfängt. Und "Problem" heißt hier "funktioniert nicht mehr".
Darum installiert Homebrew die coreutils per Default mit "g" als Namensprefix, um dererlei Probleme zu verhindern.
Homebrew sagt dir beim Installieren der coreutils, wie du sie auch mit "normalem" Namen bekommst, wenn du das unbedingt brauchst (der von dir verlinkte Beitrag besteht essentiell aus nichts anderem als diesem kopierten Text).
 
Ich bin irgendwann von Macports auf Homebrew umgestiegen, mir gefällt's besser - die Packages sind übrigens wie bei Macports auch recht up-to-date. Pakete brauchen übrigens zur Installation bei brew keine Rootrechte, das gefällt mir persönlich auch besser. Vorsicht aber, brew installiert nach /usr/local, stell sicher, dass an dem Ort nicht schon etwas installiert ist. So große Unterschiede gibt es zwischen den beiden aber nicht - in deinem Fall empfiehlt sich der Einfachheit halber Homebrew.
 
Hat dich das "g" Prefix abgeschreckt? […]

Nein. »[…]if you are coming from Linux and would like access to more "generic" *nix utilities, and a system similar to apt[…]« hat mich angesprochen.
 
Der Hauptunterschied beider ist doch praktisch der, dass Macports sich seine kleine eigene Welt in /opt/local errichtet und sämtliche Dinge von Grund auf neu kompiliert (alle Dependencies), während Homebrew sich ins "normale" /usr/local-Leben integrieren will und Dinge nur dann kompiliert, wenn auch notwendig (wenn z.B. die Version, die schon drauf ist, nicht ausreicht).
Ich bin vor inzwischen einiger Zeit auch von macports zu brew gewechselt, da ich letzteres als deutlich leichter, schlanker und einfacher empfinde, es aber nicht weniger mächtig ist und vor allem nicht ständig root Rechte benötigt (der Sinn dahinter hat sich mir nie erschlossen). Von der Syntax würde ich mich hier nicht beeinflussen lassen. Die von apt-get kenne ich jetzt zwar nicht aus dem FF, aber die von Macports kommt von BSD ports.
Homebrew hinkt nur dahingehend hinterher, dass das Projekt noch jünger ist und daher sein Repo nicht so groß wie das von Macports, persönlich vermisse ich aber schon seit Jahren nichts mehr. Es gibt zudem noch extra Homebrew Repos wie https://github.com/Homebrew/homebrew-dupes https://github.com/Homebrew/homebrew-science https://github.com/josegonzalez/homebrew-php etc.pp.

Homebrew bedarf allerdings evt. etwas Arbeit, wenn du dein /usr/local bereits voller "per Hand" kompiliertem Zeug hast. Dies sollte man optimalerweiße auch von brew managen lassen (was wunderbar simpel ist, man muss nicht mal eine Formel dafür erstellen, nur 1-2 Ordner).


Ich hatte mit Macports auch immer deutlich mehr Probleme als mit Homebrew, was aber auch an meiner damaligen Unerfahrenheit liegen kann. Macports richtet sich halt in /opt/local ein und erwartet dann, dass du ihm seine Welt nicht störst. Simples Beispiel: Macports installiert (mal wieder) eine Dependency, die eigentlich auf dem System schon vorhanden ist (evt. älter). Diese packt es natürlich in /opt/local. Hast du jetzt in deinem Pfad /usr/local weiter vorne, weil du dort selbst Sachen rein-installierst, das mit einer Dependency in /opt/local kollidiert, dann fliegt dir der Laden um die Ohren.
Homebrew geht diese Sache mMn deutlich intelligenter an, in dem es die Umgebung bei jedem Kompilieren so manipuliert, dass das zu kompilierende Programm auch nur genau die Dinge (in genau der Version) sieht, die es braucht bzw. seine Formel explizit angefragt hat.
 
  • Gefällt mir
Reaktionen: Cie
Leider hatte ich mir schon ein paar Werkzeuge in /usr/local installiert, was prompt zu Problemen führt. Ist zwar jetzt OT, aber vielleicht erlaubt ihr mir noch drei Fragen: Was muss ich über Homebrew installieren, um ext2/3-Dateisysteme verwenden zu können? Was ersetzt also OSXFUSE und fuse-ext2? OSXFUSE habe ich bei homebrew schon gefunden und ein Paket ext2fuse. Sind das die richtigen?
 
Möglich. Ausgerechnet dazu kann ich dir jetzt aber nicht helfen, da ich OSXFUSE (mit ntfs-3g) immer friedlich mit Homebrew koexistierend in /usr/local hatte (musste nur die Rechte anpassen).
 
Zurück
Oben Unten