Re: macports without XCode
/ Craig Treleaven wrote on Wed 7.Nov'12 at 9:37:41 -0400 / At 2:11 PM + 11/7/12, Federico Calboli wrote: On 7 Nov 2012, at 14:06, Jeremy Lavergne jer...@lavergne.gotdns.org wrote: Which packages if I can ask? because they might be packages that I do not want nor need. I grepped to find 148 packages using our xcode includes explicitly (xcode.*1\.0). There may be more that were manually built without using our PortGroup files. Unless these packages are essential to using macports, and thus unavoidable, 148 packages are a trivial percentage of the packages provided by macports. Couldn't I just avoid them altogether? How so? I would have imagined it's the CLT that make the difference, after all they mast be installed for macports. ...and Xcode must also be installed. We do version detection using `xcodebuild -version` (see zlib for an example). We would need an alternative to this if it's not installed. That's fine, and as I said I accept the space penalty of having to have Xcode, but I fail to see why the versioning could not be done on clang or llvm (or whatever thing is in the CLT package that could be used for this) I believe support is a big issue. It is hard enough for a port maintainer to test with multiple versions of XCode. Expanding that to multiple versions of the command line tools would make it that much worse. Requiring the full XCode install isn't a big burden for users. Things might be different if Apple was charging a non-trivial amount of money for XCode. Craig I haven't looked for ages but is the OpenDarwin project still going? I had thoughts once upon-a-time that this project might get going well enough to provide an entire Open Source platform that macports would be a great candidate for being the default package manager on; thus providing a complete OS environment that breaks away from Apple completely. Given the direction it looks like they're going in that would be fantastic. I wonder if something like that would ever happen. I've decided to stay at 10.7.x and not make the change Mountain Lion or beyond, I think someone else mentioned they were doing something similar on this list recently. But back on topic - I don't feel that having to install Xcode is a major problem really. I mean it's massive and takes an age to download but still. Especially as it would no doubt cause too much work to restructure macports to do without it. Even if one wants to build software from source without macports they still require the Xcode installation to do so. It's a good question though but I wouldn't bother giving yourself the headache of trying to work around it by not installing Xcode. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: macports without XCode
On Nov 08, 2012, at 01:29 PM, "William H. Magill" mag...@icloud.com wrote:On Nov 07, 2012, at 08:47 AM, Federico Calboli f.calb...@gmail.com wrote:After having a go with homebrew I decided that macport's use of /opt/local is significantly less likely to screw up my system, so I am now quite firmly on the macport side of the camp. One good thing homebrew has though is the fact it only requires the command line tools, not the whole Xcode installation. Is a macports -Xcode +CLT ever going to happen?I do not believe it is possible to acquire/install the Command Line Tools (CLT) WITHOUT first installing Xcode. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: macports without XCode
On 8 Nov 2012, at 18:29, William H. Magill mag...@icloud.com wrote: On Nov 07, 2012, at 08:47 AM, Federico Calboli f.calb...@gmail.com wrote: After having a go with homebrew I decided that macport's use of /opt/local is significantly less likely to screw up my system, so I am now quite firmly on the macport side of the camp. One good thing homebrew has though is the fact it only requires the command line tools, not the whole Xcode installation. Is a macports -Xcode +CLT ever going to happen? I do not believe it is possible to acquire/install the Command Line Tools (CLT) WITHOUT first installing Xcode. It is, people using homebrew (and not just them) do it all the time. BW F -- Federico Calboli f.calb...@gmail.com ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: macports without XCode
On Nov 8, 2012, at 02:12, Jamie Paul Griffin wrote: I haven't looked for ages but is the OpenDarwin project still going? I had thoughts once upon-a-time that this project might get going well enough to provide an entire Open Source platform that macports would be a great candidate for being the default package manager on; thus providing a complete OS environment that breaks away from Apple completely. Given the direction it looks like they're going in that would be fantastic. I wonder if something like that would ever happen. I've decided to stay at 10.7.x and not make the change Mountain Lion or beyond, I think someone else mentioned they were doing something similar on this list recently. The OpenDarwin project was ended in 2006, at which time the DarwinPorts project changed its name to MacPorts to indicate its focus on Apple's commercial Mac OS X operating system, as opposed to any open-source efforts based on the underlying Darwin OS. OS X remains our focus today. https://trac.macports.org/wiki/MacPortsHistory ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
macports without XCode
After having a go with homebrew I decided that macport's use of /opt/local is significantly less likely to screw up my system, so I am now quite firmly on the macport side of the camp. One good thing homebrew has though is the fact it only requires the command line tools, not the whole Xcode installation. Is a macports -Xcode +CLT ever going to happen? BW F -- Federico Calboli f.calb...@gmail.com ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: macports without XCode
After having a go with homebrew I decided that macport's use of /opt/local is significantly less likely to screw up my system, so I am now quite firmly on the macport side of the camp. One good thing homebrew has though is the fact it only requires the command line tools, not the whole Xcode installation. Is a macports -Xcode +CLT ever going to happen? Some packages provided by MacPorts are actually xcode projects; you can't them without xcode installed. Some packages also build differently based on the version of xcode installed; you also can't install them without xcode present. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: macports without XCode
On 7 Nov 2012, at 13:49, Jeremy Lavergne jer...@lavergne.gotdns.org wrote: After having a go with homebrew I decided that macport's use of /opt/local is significantly less likely to screw up my system, so I am now quite firmly on the macport side of the camp. One good thing homebrew has though is the fact it only requires the command line tools, not the whole Xcode installation. Is a macports -Xcode +CLT ever going to happen? Some packages provided by MacPorts are actually xcode projects; you can't them without xcode installed. Which packages if I can ask? because they might be packages that I do not want nor need. Some packages also build differently based on the version of xcode installed; you also can't install them without xcode present. How so? I would have imagined it's the CLT that make the difference, after all they mast be installed for macports. BW F -- Federico Calboli f.calb...@gmail.com ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: macports without XCode
Which packages if I can ask? because they might be packages that I do not want nor need. I grepped to find 148 packages using our xcode includes explicitly (xcode.*1\.0). There may be more that were manually built without using our PortGroup files. How so? I would have imagined it's the CLT that make the difference, after all they mast be installed for macports. ...and Xcode must also be installed. We do version detection using `xcodebuild -version` (see zlib for an example). We would need an alternative to this if it's not installed. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: macports without XCode
On 7 Nov 2012, at 14:06, Jeremy Lavergne jer...@lavergne.gotdns.org wrote: Which packages if I can ask? because they might be packages that I do not want nor need. I grepped to find 148 packages using our xcode includes explicitly (xcode.*1\.0). There may be more that were manually built without using our PortGroup files. Unless these packages are essential to using macports, and thus unavoidable, 148 packages are a trivial percentage of the packages provided by macports. Couldn't I just avoid them altogether? How so? I would have imagined it's the CLT that make the difference, after all they mast be installed for macports. ...and Xcode must also be installed. We do version detection using `xcodebuild -version` (see zlib for an example). We would need an alternative to this if it's not installed. That's fine, and as I said I accept the space penalty of having to have Xcode, but I fail to see why the versioning could not be done on clang or llvm (or whatever thing is in the CLT package that could be used for this) BW F -- Federico Calboli f.calb...@gmail.com ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: macports without XCode
At 2:11 PM + 11/7/12, Federico Calboli wrote: On 7 Nov 2012, at 14:06, Jeremy Lavergne jer...@lavergne.gotdns.org wrote: Which packages if I can ask? because they might be packages that I do not want nor need. I grepped to find 148 packages using our xcode includes explicitly (xcode.*1\.0). There may be more that were manually built without using our PortGroup files. Unless these packages are essential to using macports, and thus unavoidable, 148 packages are a trivial percentage of the packages provided by macports. Couldn't I just avoid them altogether? How so? I would have imagined it's the CLT that make the difference, after all they mast be installed for macports. ...and Xcode must also be installed. We do version detection using `xcodebuild -version` (see zlib for an example). We would need an alternative to this if it's not installed. That's fine, and as I said I accept the space penalty of having to have Xcode, but I fail to see why the versioning could not be done on clang or llvm (or whatever thing is in the CLT package that could be used for this) I believe support is a big issue. It is hard enough for a port maintainer to test with multiple versions of XCode. Expanding that to multiple versions of the command line tools would make it that much worse. Requiring the full XCode install isn't a big burden for users. Things might be different if Apple was charging a non-trivial amount of money for XCode. Craig ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: macports without XCode
On 11/7/12 3:06 PM, Jeremy Lavergne wrote: I grepped to find 148 packages using our xcode includes explicitly (xcode.*1\.0). There may be more that were manually built without using our PortGroup files. please print the list ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: macports without XCode
(base)newmbp:ports mateo$ (grep -lR 'PortGroup.*xcode.*1\.0' .|xargs -n 1 dirname )|tee /dev/tty|wc ./_resources/port1.0/group ./aqua/AppHack ./aqua/AppKiDo ./aqua/AquaLess ./aqua/aquaterm ./aqua/ArpSpyX ./aqua/arrsync ./aqua/AssignmentTrackerX ./aqua/BGHUDAppKit ./aqua/BiggerSQL ./aqua/binclocken ./aqua/BwanaDik ./aqua/Chmox ./aqua/CocoaDialog ./aqua/CosmicDebris ./aqua/cotvnc ./aqua/CronniX ./aqua/DateLine ./aqua/DesktopManager ./aqua/dnsupdate ./aqua/FFView ./aqua/Fonzy ./aqua/Freecell ./aqua/FScript ./aqua/fugu ./aqua/GetPoints ./aqua/gimp-app ./aqua/GPGAppKit ./aqua/Growl ./aqua/HideSysFiles ./aqua/huevos ./aqua/IcyJuice ./aqua/ihook ./aqua/istumbler ./aqua/iTerm ./aqua/iTerm2 ./aqua/iTunesMatchHelper ./aqua/launch ./aqua/Lingon ./aqua/MacBiff ./aqua/macsword ./aqua/MailtoMutt ./aqua/ManOpen ./aqua/MenuMeters ./aqua/mkconsole ./aqua/MongoExplorer ./aqua/MyLoss ./aqua/namebench ./aqua/NotificationWatcher ./aqua/osx2x ./aqua/OSXPal ./aqua/pixen ./aqua/Platypus ./aqua/Platypus44 ./aqua/PRICE-aqua ./aqua/PsyncX ./aqua/QMK-Groundstation ./aqua/qt4-mac ./aqua/qt4-mac-devel ./aqua/qt4-mac-mysql55-plugin ./aqua/qt4-mac-postgresql91-plugin ./aqua/qt4-mac-sqlite2-plugin ./aqua/Quicksilver ./aqua/Readown ./aqua/ShiftIt ./aqua/Shiira2 ./aqua/SIDPLAY ./aqua/sloth ./aqua/Smultron ./aqua/SSHKeychain ./aqua/terminal-notifier ./aqua/TeXShop ./aqua/TeXShop3 ./aqua/vineserver ./aqua/wtf-x ./aqua/X-MasTree ./aqua/xrg ./archivers/keka ./archivers/zlib ./audio/cfxr ./audio/ID3 ./audio/libsdl_sound-framework ./audio/midi_patchbay ./audio/openal ./comms/rgm3800 ./devel/activewire ./devel/agprocess ./devel/bootstrap_cmds ./devel/BWToolkit ./devel/chromium-tabs ./devel/class-dump ./devel/curlhandle ./devel/darwinbuild ./devel/developer_cmds ./devel/GitX ./devel/gpgme-objc ./devel/kdiff3 ./devel/libsdl ./devel/MacPorts_Framework ./devel/macstl ./devel/mogenerator ./devel/ode ./devel/ois ./devel/otx ./devel/VillainousStyle ./editors/ackmate ./editors/bean ./editors/hexfiend ./editors/textmate2 ./fuse/fuse4x-framework ./fuse/fuse4x-kext ./fuse/sshfs-gui ./games/Gomoku ./games/Gridlock ./games/PCLauncher ./gnome/gtk2 ./gnome/gtk3 ./graphics/cairo ./graphics/cairo-devel ./graphics/glitz ./graphics/graphviz ./graphics/graphviz-devel ./graphics/graphviz-gui ./graphics/graphviz-gui-devel ./graphics/openvrml ./graphics/Paintbrush ./graphics/rt-volume-rendering ./graphics/tiff ./graphics/twain-sane ./lang/fscript-cli ./mail/GNUMail-Aqua ./math/gnuplot ./math/nestedsums ./math/R-app ./multimedia/ffmpeg ./multimedia/ffmpeg-devel ./multimedia/libtheora ./multimedia/x264 ./multimedia/XBMC ./net/transmission ./news/PlopFolio ./science/geomview ./science/liboglappth ./science/miriad ./science/molden ./sysutils/arq_restore ./sysutils/burn-app ./sysutils/ImageSnap ./sysutils/macports-notifier ./sysutils/osxutils ./sysutils/Pallet ./sysutils/sleepnow ./sysutils/sleepwatcher ./sysutils/xattr ./tex/LaTeXiT 155 1552818 (base)newmbp:ports mateo$ On 08/11/2012, at 7:24 AM, Markus Neuenschwander guanoape...@gmx.ch wrote: On 11/7/12 3:06 PM, Jeremy Lavergne wrote: I grepped to find 148 packages using our xcode includes explicitly (xcode.*1\.0). There may be more that were manually built without using our PortGroup files. please print the list ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
