Re: Side effects?
Hi, > I just want to point out that this is where having a gui that is open > source would really help: the responsibility wouldn't have to be > shouldered by just one person. I don't see how those two comments are connected. Just because an application is developed in Xcode, using cocoa etc., does not mean that the code base cannot be hosted in svn or git, and publicly available, so anyone who wishes to can check out and hack, with multiple people having write access. Handbrake is on application that springs to mind with a native coca OSX GUI that does just this (In fact handbrake does go to the effort of maintaining difficult UIs on the various platforms it supports, OSX, windows and Linux, simple to avoid the 'one size doesn't quite fit all' issue with cross platform toolkits.) FWIW, I agree with the sentiments that in this case,where it is only ever going to run on OSX, you will get the best looking end result (by which I mean most like any other OSX application) by using the native Xcode toolkit. Chris > ___ > macports-users mailing list > macports-users@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Advanced configuration of SMLNJ
On Jan 31, 2013, at 20:43, Lawrence Velázquez wrote: > Are you referring to reinplace? It's mostly used for in-place substitutions, > like sed. I'm not even sure it can do anything else; I've never tried. reinplace runs sed under the hood. Flags probably differ. http://trac.macports.org/browser/trunk/base/src/port1.0/portutil.tcl?rev=101985#L915 ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Side effects?
On Thu, Jan 31, 2013 at 8:25 PM, Lawrence Velázquez wrote: > On Jan 31, 2013, at 8:46 PM, Sean Farley wrote: > >> I just want to point out that this is where having a gui that is open >> source would really help: the responsibility wouldn't have to be >> shouldered by just one person. > > This is technically true, but GUI development is one broth that is *very* > easily spoiled by too many cooks. Yeah, that's a fair point. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Advanced configuration of SMLNJ
On Jan 31, 2013, at 9:06 PM, Watson Ladd wrote: > Does anyone have strong opinions on how SMLNJ 110.75 should be configured? > They support some incompatible options, and I want to turn on more then the > most basic ones but am not sure what set should be. You might want to enable a fair number of options by default and add conflicting variants for incompatible options. > Also if anyone has guidance on how to use the rewrite facilities of Macports > that would be appreciated. The former portfile is a guide, but I would > appreciate some more information about what to do and what not to do. Is it > basically sed on steroids? Are you referring to reinplace? It's mostly used for in-place substitutions, like sed. I'm not even sure it can do anything else; I've never tried. If at all possible, we prefer the use of patches over reinplace, because patches fail loudly if they can't be applied, while reinplace silently does nothing. Patches also provide context. Any reinplaces that do not involve a variable (e.g., the last 3 reinplaces in smlnj's configure block) should be patches instead. vq ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Side effects?
On Jan 31, 2013, at 8:46 PM, Sean Farley wrote: > I just want to point out that this is where having a gui that is open > source would really help: the responsibility wouldn't have to be > shouldered by just one person. This is technically true, but GUI development is one broth that is *very* easily spoiled by too many cooks. vq ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Side effects?
On 01/02/2013, at 11:04 AM, Kevin Walzer wrote: > Hmmm, seems port has learned some new tricks over the years that I wasn't > aware of . :-) Kudos. Another thing a GUI can do is encapsulate tricks like that, which are not easy to find in "man port" unless you know they are already there … :-) There is also the question of error reporting. This list is full of users getting into difficulties with Macports (which is where this thread started IIRC) and time and time again we see "Attach a log", "Where do I find a log?", etc. Maybe a GUI could standardise some of what happens when a build fails and save everybody some time. Finally, I can remember my own first experiences with Macports. I went straight for the jackpot --- "sudo port install kdegames4". That would have been fine on the GUI I had used for years in Linux, OpenSuSE Yast2, because all packages are binary and most dependencies are in the initial Linux installation. Some hours later … with a new Macbook Pro that was feeling dangerously hot … and with vital notes re DBus and KDE-based installations scrolling up faster than I could read them … all a bit hair-raising for a newbie. Luckily I was a hard-bitten veteran, but new to the Macbook and Macports, so I did not panic ... I think a GUI could, for example, check the dependencies and warn if there are going to be a lot of them. It could also retain notes in a pane or under a button, to be ready for review when the install is complete. Well, my 2c … oh, and I just discovered, after about 18 months' use of Macports, the "port notes" command, so please don't any CLI jockeys point that out … :-) Cheers, Ian W. P.S. I *love* CLI, its brevity and sheer power, but GUI can open up a whole new world to non expert users. See: http://www.guidebookgallery.org/articles/microelectronicsandthepersonalcomputer "Microelectronics and the Personal Computer", Scientific American, Sept 1977, by Alan C Kay, the guy who started it all … The article still reads pretty well. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Advanced configuration of SMLNJ
Hello, Does anyone have strong opinions on how SMLNJ 110.75 should be configured? They support some incompatible options, and I want to turn on more then the most basic ones but am not sure what set should be. Note this will be for a portfile that hopefully will work on your machine as well, and without forcing you to change things too much. Also if anyone has guidance on how to use the rewrite facilities of Macports that would be appreciated. The former portfile is a guide, but I would appreciate some more information about what to do and what not to do. Is it basically sed on steroids? Sincerely, Watson Ladd ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Side effects?
On Jan 31, 2013, at 19:34, Ian Wadham wrote: >> Interface Builder. It's part of Xcode. >> >> http://en.wikipedia.org/wiki/Interface_Builder > > Thanks, Ryan. That looks good. It's not exactly lying around on the surface > in Xcode, though. FWICG, you have to use File->New… and ask for a XIB > file(?). I would say using Interface Builder is fundamental to writing a GUI application on OS X. Using Xcode to its fullest potential, and how to develop a Mac app, are not things I think one can easily intuit by just opening Xcode and poking around in it. There are many tutorials out there, even entire courses, that teach this. There was a nice Stanford course on iOS development with Cocoa touch that you can find for free on iTunesU; it looked pretty good, but is of course tailored for iOS development; maybe there's one tailored for OS X development. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Side effects?
On Thu, Jan 31, 2013 at 7:34 PM, Ian Wadham wrote: > On 01/02/2013, at 11:05 AM, Ryan Schmidt wrote: >> On Jan 31, 2013, at 16:53, Ian Wadham wrote: >>> I did "sudo port install -k -s pallet" >> >> Single-letter flags like -k and -s have no effect unless you put them >> immediately after the word "port". >> >> sudo port -k -s install Pallet > > Oops. That's what I actually "commanded" but not what I emailed. > >>> I am unfamiliar with both Objective C and the Macports structure … :-( >>> >>> However, I am familiar with C++, Qt and Qt Designer (a forms designer >>> and code generator for Qt-based GUIs). Is there a forms designer for >>> Mac, BTW? Hand-coding of widgets can be laborious ... >> >> Interface Builder. It's part of Xcode. >> >> http://en.wikipedia.org/wiki/Interface_Builder > > Thanks, Ryan. That looks good. It's not exactly lying around on the surface > in Xcode, though. FWICG, you have to use File->New… and ask for a XIB > file(?). > >>> Or maybe I could prototype in C++ and Qt while boning up on Xcode >>> and Cocoa … BTW I have OS X 10.7.5 Lion and Xcode 4.2.1. Would >>> those be OK as a platform, from Macports' point of view? >> >> Yes, but please update to Xcode 4.6. It's a free update for Lion or Mountain >> Lion users on the Mac App Store or at Apple Developer Connection. > > Will do. > >> My opinion is that cross-platform frameworks like Qt or wxWidgets or Java >> result in programs that don't look at home on any platform, especially not >> OS X which has a very specific interface design aesthetic, and which are >> also far larger and slower than if they had been written to the target OS >> directly. If cross-platform compatibility is your primary interest and you >> cannot afford to create separate native interfaces for each of your target >> platforms then so be it. But for a MacPorts GUI, which need only run on OS >> X, I strongly suspect that the best user experience will result from writing >> in Objective-C with Cocoa. > > I tend to agree in this case. No need for a Macports GUI to be > cross-platform. > > However, for me there is a learning curve to be climbed on Objective C, Cocoa > and Xcode. I don't know if I have the energy for that. I will be 75 next > month and > I wrote my first computer program about 50 years ago in Autocoder on a Ferrant > Sirius, which is now in a local museum. So don't expect too much … :-) I just want to point out that this is where having a gui that is open source would really help: the responsibility wouldn't have to be shouldered by just one person. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Side effects?
On 01/02/2013, at 11:05 AM, Ryan Schmidt wrote: > On Jan 31, 2013, at 16:53, Ian Wadham wrote: >> I did "sudo port install -k -s pallet" > > Single-letter flags like -k and -s have no effect unless you put them > immediately after the word "port". > > sudo port -k -s install Pallet Oops. That's what I actually "commanded" but not what I emailed. >> I am unfamiliar with both Objective C and the Macports structure … :-( >> >> However, I am familiar with C++, Qt and Qt Designer (a forms designer >> and code generator for Qt-based GUIs). Is there a forms designer for >> Mac, BTW? Hand-coding of widgets can be laborious ... > > Interface Builder. It's part of Xcode. > > http://en.wikipedia.org/wiki/Interface_Builder Thanks, Ryan. That looks good. It's not exactly lying around on the surface in Xcode, though. FWICG, you have to use File->New… and ask for a XIB file(?). >> Or maybe I could prototype in C++ and Qt while boning up on Xcode >> and Cocoa … BTW I have OS X 10.7.5 Lion and Xcode 4.2.1. Would >> those be OK as a platform, from Macports' point of view? > > Yes, but please update to Xcode 4.6. It's a free update for Lion or Mountain > Lion users on the Mac App Store or at Apple Developer Connection. Will do. > My opinion is that cross-platform frameworks like Qt or wxWidgets or Java > result in programs that don't look at home on any platform, especially not OS > X which has a very specific interface design aesthetic, and which are also > far larger and slower than if they had been written to the target OS > directly. If cross-platform compatibility is your primary interest and you > cannot afford to create separate native interfaces for each of your target > platforms then so be it. But for a MacPorts GUI, which need only run on OS X, > I strongly suspect that the best user experience will result from writing in > Objective-C with Cocoa. I tend to agree in this case. No need for a Macports GUI to be cross-platform. However, for me there is a learning curve to be climbed on Objective C, Cocoa and Xcode. I don't know if I have the energy for that. I will be 75 next month and I wrote my first computer program about 50 years ago in Autocoder on a Ferrant Sirius, which is now in a local museum. So don't expect too much … :-) Cheers, Ian W. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Testing php5x-oracle In 64bit Mode?
On Jan 31, 2013, at 19:21, "Wilks, Daniel" wrote: > Looks like Oracle finally released a new version of the OSX Instant Client - > 11.2.0.3.0. This one might work in 64-bit mode. Thanks for letting me know! Would you please file a ticket in the issue tracker? I can look at it tomorrow. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Testing php5x-oracle In 64bit Mode?
Hi, Looks like Oracle finally released a new version of the OSX Instant Client - 11.2.0.3.0. This one might work in 64-bit mode. I might know just enough to be dangerous, how would one go about locally modifying php's Portfile to remove the supported_archs i386 in the oracle subport so I can see? Thanks, Dan ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Side effects?
On Jan 31, 2013, at 16:53, Ian Wadham wrote: > I did "sudo port install -k -s pallet" Single-letter flags like -k and -s have no effect unless you put them immediately after the word "port". sudo port -k -s install Pallet > I am unfamiliar with both Objective C and the Macports structure … :-( > > However, I am familiar with C++, Qt and Qt Designer (a forms designer > and code generator for Qt-based GUIs). Is there a forms designer for > Mac, BTW? Hand-coding of widgets can be laborious ... Interface Builder. It's part of Xcode. http://en.wikipedia.org/wiki/Interface_Builder > I could write something in C++ and Qt, but that might cause a chicken > and egg problem down the line, i.e. to use the GUI you would first have > to install qt4-mac. Also it takes quite a while to install qt4-mac from the > command line, even as a binary package, which might be a turnoff for > beginning users. Installing a binary should be mostly limited by the speed of your network connection, and the speed of your disk to unpack the compressed binary. > Or maybe I could prototype in C++ and Qt while boning up on Xcode > and Cocoa … BTW I have OS X 10.7.5 Lion and Xcode 4.2.1. Would > those be OK as a platform, from Macports' point of view? Yes, but please update to Xcode 4.6. It's a free update for Lion or Mountain Lion users on the Mac App Store or at Apple Developer Connection. My opinion is that cross-platform frameworks like Qt or wxWidgets or Java result in programs that don't look at home on any platform, especially not OS X which has a very specific interface design aesthetic, and which are also far larger and slower than if they had been written to the target OS directly. If cross-platform compatibility is your primary interest and you cannot afford to create separate native interfaces for each of your target platforms then so be it. But for a MacPorts GUI, which need only run on OS X, I strongly suspect that the best user experience will result from writing in Objective-C with Cocoa. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Side effects?
Hmmm, seems port has learned some new tricks over the years that I wasn't aware of . :-) Kudos. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Side effects?
On Jan 31, 2013, at 17:26, Kevin Walzer wrote: > On 1/31/13 6:11 PM, James Linder wrote: >> CLI does the job nicely and well, why on earth would you seek to make an >> easy, automateable task hard/impossible. > > Here are a few things that a GUI can do that the CLI cannot: > > 1. Filter ports by category. port offers no way to see all the "aqua" ports, > for instance. Sure it can. $ port list category:aqua abiword@2.4.5 editors/abiword ackmate@1.1.2 editors/ackmate adium @1.3.0 net/adium AppHack@1.1aqua/AppHack AppKiDo@0.988 aqua/AppKiDo AquaLess @1.6aqua/AquaLess aquaterm @1.1.1 aqua/aquaterm arora @0.11.0 www/arora ArpSpyX@1.1aqua/ArpSpyX ^C MacPorts can filter on tons of things. It even has Boolean logic. How about: $ port echo name:^php and not maintainer:ryandesign php-gearman php-gtk php-igbinary php-midgard2 php-mode.el php-suhosin php-Twig php-uuid ^C > 2. Browse and sort ports visually. "port list" dumps all available ports to > the Terminal, but you can't sort them with a single click. "port list" lists those ports you've asked it to list; if you don't ask it to list anything specific, it lists them all. True, sorting in the terminal is more cumbersome. > 3. Get the homepage of a port with a click. A GUI can format web pages as > hyperlinks, but "port info" can't. But we do have "port gohome" which takes you to a port's homepage. > 4. Save yourself from fat-fingering the command invocation to install a > particular port. > > CLI is an essential tool, and for uber-power-users it may be easier than a > GUI. But for a high-level view of MacPorts, the GUI is better, in my view. Even I find many of my interactions with MacPorts on the command line repetitive and needing much too much typing; a GUI could make some tasks easier. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Side effects?
On 1/31/13 6:11 PM, James Linder wrote: CLI does the job nicely and well, why on earth would you seek to make an easy, automateable task hard/impossible. Also: a GUI can be automated as well. I've added an AppleScript API to PortAuthority, for instance. -- Kevin Walzer Code by Kevin http://www.codebykevin.com ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Side effects?
On Thu, Jan 31, 2013 at 11:53 PM, Ian Wadham wrote: > > I could write something in C++ and Qt, but that might cause a chicken > and egg problem down the line, i.e. to use the GUI you would first have > to install qt4-mac. Such a program could be packaged as a standalone Mac application (without any chickens involved). Mojca ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Side effects?
On 1/31/13 6:11 PM, James Linder wrote: CLI does the job nicely and well, why on earth would you seek to make an easy, automateable task hard/impossible. Here are a few things that a GUI can do that the CLI cannot: 1. Filter ports by category. port offers no way to see all the "aqua" ports, for instance. 2. Browse and sort ports visually. "port list" dumps all available ports to the Terminal, but you can't sort them with a single click. 3. Get the homepage of a port with a click. A GUI can format web pages as hyperlinks, but "port info" can't. 4. Save yourself from fat-fingering the command invocation to install a particular port. CLI is an essential tool, and for uber-power-users it may be easier than a GUI. But for a high-level view of MacPorts, the GUI is better, in my view. -- Kevin Walzer Code by Kevin http://www.codebykevin.com ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Side effects?
On 01/02/2013, at 4:00 AM, macports-users-requ...@lists.macosforge.org wrote: >> It is routinely a GSoC project, and since we were not chosen last year it >> has definitely fallen behind. >> >>> BTW, does Macports have a nice safe GUI? > > If I knew what tools to use on Apple Mac, I might have a crack > at it myself. I have had quite a bit of experience with designing > and programming GUIs, databases, SQL, Shell scripts and an > in-house GUI-based build system where I used to work. Ian I just poured boiling water on the idea :-) but Qt from macports works well, is easy and is nice. It frees the 'simple clean and nice language buried in C++' (not my words). It is very configurable, I don't like apple's No Mnumonics and hijack the menu to the toolbar. Qt lets me do it my way. James ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Side effects?
On 01/02/2013, at 4:00 AM, macports-users-requ...@lists.macosforge.org wrote: >> >> One time funding (pay for a task) is (arguably) different than routinely >> asking for money. We have had trolls in the past like that, simply feeding >> off people. > > Well, I don't think I'm a troll...for a long time PortAuthority was the > only viable GUI tool for MacPorts. See this ancient blog entry calling > for a MacPorts GUI at GSoc: > > http://ihack.us/2008/03/24/building-a-gui-for-macports/ > > Dr. Ernie called PA a "clever" product and the "state-of-the-art" at the > time. > > GUI programming is hard. I think that's one reason why a free, > open-source GUI tool for MacPorts has never really taken off: I have > literally watched such tools come and go over the past eight or nine > years that I've been a MacPorts (formerly DarwinPorts) user. > > One reason I'm still at it is PA provides a modest amount of income for > me. And if PA makes MacPorts more usable to some, and attracts more > users, then that's to MacPorts' benefit as well. > > If a professional-level, full-featured, open-source GUI tool for > MacPorts came along, I'm sure the community would embrace it. I would > certainly welcome the competition. But finding someone devoted enough to > do that level of work, for free, as a volunteer, is a real challenge. > No free/OSS GUI tool for MacPorts comparable in professionalism to > Fink's FinkCommander has ever emerged. Actually, speaking for myself, I think that a GUI interface would be most horrid. CLI does the job nicely and well, why on earth would you seek to make an easy, automateable task hard/impossible. 'Course I speak from the perspective of someone who went to great effort to get arduino to build with make, and just for the record I write Qt stuff where appropriate. James ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Side effects?
On Jan 31, 2013, at 5:53 PM, Ian Wadham wrote: > I did "sudo port install -k -s pallet" and then started digging around in > the Macports directory structure for Pallet and some source code. > Eventually I found: > > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_Pallet/Pallet/work/Pallet > > which contained some *.m and *.h files. Is that the right stuff? It is, but you might as well just check out the source directly: https://trac.macports.org/browser/contrib/Pallet vq ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Side effects?
On 31/01/2013, at 11:42 PM, Ryan Schmidt wrote: > On Jan 31, 2013, at 06:07, Ian Wadham wrote: >> On 31/01/2013, at 2:37 PM, Jeremy Lavergne wrote: >> >>> It is routinely a GSoC project, and since we were not chosen last year it >>> has definitely fallen behind. >>> BTW, does Macports have a nice safe GUI? >> >> If I knew what tools to use on Apple Mac, I might have a crack >> at it myself. I have had quite a bit of experience with designing >> and programming GUIs, databases, SQL, Shell scripts and an >> in-house GUI-based build system where I used to work. > > The tools to use on the Mac are Xcode and a knowledge of Cocoa. > > You could always start by reading the code for Pallet, which is in our > repository. Or even fork Pallet and work on improving it, with either the > goal of improving Pallet or just learning enough about Cocoa and how to > integrate with the MacPorts Framework to begin your own GUI from scratch. Thanks for the info, Ryan. I did "sudo port install -k -s pallet" and then started digging around in the Macports directory structure for Pallet and some source code. Eventually I found: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_Pallet/Pallet/work/Pallet which contained some *.m and *.h files. Is that the right stuff? I am unfamiliar with both Objective C and the Macports structure … :-( However, I am familiar with C++, Qt and Qt Designer (a forms designer and code generator for Qt-based GUIs). Is there a forms designer for Mac, BTW? Hand-coding of widgets can be laborious ... I could write something in C++ and Qt, but that might cause a chicken and egg problem down the line, i.e. to use the GUI you would first have to install qt4-mac. Also it takes quite a while to install qt4-mac from the command line, even as a binary package, which might be a turnoff for beginning users. Or maybe I could prototype in C++ and Qt while boning up on Xcode and Cocoa … BTW I have OS X 10.7.5 Lion and Xcode 4.2.1. Would those be OK as a platform, from Macports' point of view? I also had a quick look at Tcl/Tk at http://www.bin-co.com/tcl/tutorial/ It's a bit too Shell-like for me … :-) I am quite at home in Shell scripts, but am rather wary of using them when not absolutely necessary. Cheers, Ian W. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: How do I link with Aquaterm library for an external build?
On Jan 31, 2013, at 11:32, Brandon Allbery wrote: > On Thu, Jan 31, 2013 at 6:57 AM, Mojca Miklavec wrote: > Actually, you usually need both -framework AquaTerm and > -F/opt/local/Library/Frameworks when compiling, as in: > gcc hello.c -framework AquaTerm -F/opt/local/Library/Frameworks > > -F is to -I as -framework is to -l. That is, -F gets you the framework's > include files, -framework gets you its libraries. Doesn't -F do for frameworks not only what -I does for includes but also what -L does for libraries? ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: How do I link with Aquaterm library for an external build?
On Thu, Jan 31, 2013 at 6:57 AM, Mojca Miklavec wrote: > Actually, you usually need both -framework AquaTerm and > -F/opt/local/Library/Frameworks when compiling, as in: > gcc hello.c -framework AquaTerm -F/opt/local/Library/Frameworks > -F is to -I as -framework is to -l. That is, -F gets you the framework's include files, -framework gets you its libraries. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Side effects?
On 1/31/13 9:27 AM, Mojca Miklavec wrote: Or simply taking Qt, Tcl/Tk or any other cross-platform tool for GUIs that works on Mac OS X (and doesn't require any special knowledge of Cocoa if an otherwise motivated developer doesn't feel comfortable writing in Cocoa). PortAuthority is written in Tcl/Tk, precisely because I don't like using Cocoa for application development. I'm one of the core maintainers of Tk on the Mac, which does require knowledge of Cocoa--in addition to maintaining Tk ittself I've also written a lot of open-source libraries to hook Tcl/Tk into various parts of the Cocoa API--but I really dislike Xcode and its model of development. I'm an Aquamacs/Terminal type of developer, thanks. :-) -- Kevin Walzer Code by Kevin http://www.codebykevin.com ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Side effects?
On Thu, Jan 31, 2013 at 1:42 PM, Ryan Schmidt wrote: > On Jan 31, 2013, at 06:07, Ian Wadham wrote: > >> If I knew what tools to use on Apple Mac, I might have a crack >> at it myself. I have had quite a bit of experience with designing >> and programming GUIs, databases, SQL, Shell scripts and an >> in-house GUI-based build system where I used to work. > > The tools to use on the Mac are Xcode and a knowledge of Cocoa. Or simply taking Qt, Tcl/Tk or any other cross-platform tool for GUIs that works on Mac OS X (and doesn't require any special knowledge of Cocoa if an otherwise motivated developer doesn't feel comfortable writing in Cocoa). Mojca ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Side effects?
Back when it still worked (it wasn't updated for Lion or MacPorts 2.x), Porticus was my favorite - it let one see port options (or choose them for a newly installed port), let one do forced installs if needed, etc. Very little I'd routinely do that I couldn't do through it. Sadly, I've written just about zero in either Objective-C or using Xcode IDE...so my learning curve to try and get it updated would be very steep. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Side effects?
On 01/31/2013 12:42 PM, Ryan Schmidt wrote: > > On Jan 31, 2013, at 06:07, Ian Wadham wrote: > >> On 31/01/2013, at 2:37 PM, Jeremy Lavergne wrote: >> >>> It is routinely a GSoC project, and since we were not chosen last year it >>> has definitely fallen behind. >>> BTW, does Macports have a nice safe GUI? >> >> If I knew what tools to use on Apple Mac, I might have a crack >> at it myself. I have had quite a bit of experience with designing >> and programming GUIs, databases, SQL, Shell scripts and an >> in-house GUI-based build system where I used to work. > > The tools to use on the Mac are Xcode and a knowledge of Cocoa. > > You could always start by reading the code for Pallet, which is in our > repository. Or even fork Pallet and work on improving it, with either the > goal of improving Pallet or just learning enough about Cocoa and how to > integrate with the MacPorts Framework to begin your own GUI from scratch. I've built several things in Cocoa on OS X after pulling them from Github & still build my own MacVim using the same route. On Snow Leopard, Xcode is pretty straightforward (I used 'Xcode 3 Unleashed' by Fritz Anderson as my guide in the first instance. Recommended). I can't vouch for it on Lion or Mountain Lion though (I unsubscribed from Apple's cocoa-dev & Xcode mailing lists some time ago after the list went into a little bit of a meltdown over all the changes brought about by Xcode 4). What I will say for it is is that it's a hell of a lot easier than working with the old Classic Mac OS although I still have a soft spot for MPW (the Macintosh Programmer's Workshop). That was a nightmare & nearly put me off code of *any* sort although, again, it was miles better than Visual Studio... There's plenty of documentation out there, so give it a try. I never found a project/idea I could pursue so this one could be promising for someone. What's to lose? :-) Cheers, Phil... -- currently (ab)using CentOS 5.8 & 6.3, Debian Squeeze & Wheezy, Fedora Beefy & Spherical, Lubuntu 12.10, OS X Snow Leopard & Ubuntu Precise & Quantal signature.asc Description: OpenPGP digital signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Side effects?
On Jan 30, 2013, at 22:10, Kevin Walzer wrote: > On 1/30/13 10:57 PM, Jeremy Lavergne wrote: >> One time funding (pay for a task) is (arguably) different than routinely >> asking for money. We have had trolls in the past like that, simply feeding >> off people. > > Well, I don't think I'm a troll...for a long time PortAuthority was the only > viable GUI tool for MacPorts. See this ancient blog entry calling for a > MacPorts GUI at GSoc: > > http://ihack.us/2008/03/24/building-a-gui-for-macports/ > > Dr. Ernie called PA a "clever" product and the "state-of-the-art" at the time. > > GUI programming is hard. I think that's one reason why a free, open-source > GUI tool for MacPorts has never really taken off: I have literally watched > such tools come and go over the past eight or nine years that I've been a > MacPorts (formerly DarwinPorts) user. > > One reason I'm still at it is PA provides a modest amount of income for me. > And if PA makes MacPorts more usable to some, and attracts more users, then > that's to MacPorts' benefit as well. > > If a professional-level, full-featured, open-source GUI tool for MacPorts > came along, I'm sure the community would embrace it. I would certainly > welcome the competition. But finding someone devoted enough to do that level > of work, for free, as a volunteer, is a real challenge. No free/OSS GUI tool > for MacPorts comparable in professionalism to Fink's FinkCommander has ever > emerged. I've glanced at PortAuthority before but haven't used it because of the cost barrier and because I'm happy working in the Terminal. (I've also only glanced at Pallet, even though it's free.) But I'm glad PA exists for those users who would rather use a nice polished GUI. I've wondered whether PA is profitable, and I'm glad to hear that it is. Kevin is following the time-honored tradition of adding a paid closed-source component on top of a free open-source offering. (OS X itself is another example of that business model.) We should all be so lucky as to pull that off successfully! :) ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Side effects?
On Jan 31, 2013, at 06:07, Ian Wadham wrote: > On 31/01/2013, at 2:37 PM, Jeremy Lavergne wrote: > >> It is routinely a GSoC project, and since we were not chosen last year it >> has definitely fallen behind. >> >>> BTW, does Macports have a nice safe GUI? > > If I knew what tools to use on Apple Mac, I might have a crack > at it myself. I have had quite a bit of experience with designing > and programming GUIs, databases, SQL, Shell scripts and an > in-house GUI-based build system where I used to work. The tools to use on the Mac are Xcode and a knowledge of Cocoa. You could always start by reading the code for Pallet, which is in our repository. Or even fork Pallet and work on improving it, with either the goal of improving Pallet or just learning enough about Cocoa and how to integrate with the MacPorts Framework to begin your own GUI from scratch. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Side effects?
On 31/01/2013, at 2:37 PM, Jeremy Lavergne wrote: > It is routinely a GSoC project, and since we were not chosen last year it has > definitely fallen behind. > >> BTW, does Macports have a nice safe GUI? If I knew what tools to use on Apple Mac, I might have a crack at it myself. I have had quite a bit of experience with designing and programming GUIs, databases, SQL, Shell scripts and an in-house GUI-based build system where I used to work. Cheers, Ian W. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: How do I link with Aquaterm library for an external build?
On Thu, Jan 31, 2013 at 12:14 PM, Ryan Schmidt wrote: > On Jan 31, 2013, at 02:21, Jerry wrote: >> On Jan 30, 2013, at 3:42 PM, Ryan Schmidt wrote: >> >>> If you want those three values to be in CFLAGS, you'll have to enclose them >>> in quotes: >>> >>> CFLAGS="-F/opt/local/Library/Frameworks -framework AquaTerm" >> >> Thanks, Ryan. >> >> I entered this line with quotes in my script followed by >> export CFLAGS >> (and removed the symlink I mentioned earlier) but Aquaterm was not >> found--PLplot still builds without the Aquaterm option. There are lots of >> occurrences of things like this which I don't understand: >> >> cd /usr/local/plplot_build_dir/examples/c && /usr/bin/gcc >> -F/opt/local/Library/Frameworks -framework AquaTerm >> -I/Users/me/Documents/Programs/Ada/Code/Bindings/PLplot/plplot_svn/plplot/include >> -I/usr/local/plplot_build_dir/include >> -I/Users/me/Documents/Programs/Ada/Code/Bindings/PLplot/plplot_svn/plplot/lib/qsastime >> -DUSINGDLL -o CMakeFiles/x33c.dir/x33c.c.o -c >> /Users/me/Documents/Programs/Ada/Code/Bindings/PLplot/plplot_svn/plplot/examples/c/x33c.c >> i686-apple-darwin11-llvm-gcc-4.2: -framework: linker input file unused >> because linking not done >> i686-apple-darwin11-llvm-gcc-4.2: AquaTerm: linker input file unused because >> linking not done > > I'm not an expert on writing Makefiles or CMakeLists.txt; I tend to mostly > package up software others have written that already have correctly-written > build scripts. > > As far as I know, "-framework Foo" is to frameworks as "-lfoo" is to > libraries, so it belongs in LDFLAGS and not CFLAGS. Oh, I'm sorry. Actually, you usually need both -framework AquaTerm and -F/opt/local/Library/Frameworks when compiling, as in: gcc hello.c -framework AquaTerm -F/opt/local/Library/Frameworks but -framework indeed seems to be just for the linker and you get a warning (or at least it doesn't seem like an error to me - the object file gets generated) if you use -framework together with "-c". So please try to add -F/opt/local/Library/Frameworks to both CFLAGS and LDFLAGS and try again. I took a loot at the source code, the file FindAQT.cmake in particular. But while you could define CFLAGS and LDFLAGS manually, one thing that's not really clear to me is how that would help CMake find the framework. The only command that's used in the file is: FIND_FILE(AQT_FRAMEWORK AquaTerm/AQTAdapter.h) and I don't understand how this suffices to find the file /opt/local/Library/Frameworks/AquaTerm.framework/Headers/AQTAdapter.h Also, even if it would find it, it doesn't set any flag anywhere. If you understand autoconf, you can take a look at MacPorts' patch for gnuplot that takes care of finding the right instance of AquaTerm. I would suggest you to allow setting -DAQUATERM_FRAMEWORK_PATH or something similar that would define where FindAQT should first look for AQTAdapter.h. I just tried to run ccmake on the trunk version of PLplot, but it first goes crazy and then reports an error: CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: ITCL_LIBRARY (I'm not sure if that's the only error). I can try to help, but the prerequisite for that is that I know how to compile the program in the first place. Mojca PS: should this discussion be moved to the dev mailing list perhaps? ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Side effects?
On 31/01/2013, at 2:53 PM, Kevin Walzer wrote: > On 1/30/13 10:50 PM, Jeremy Lavergne wrote: >> Don't remember that one. Certainly not one that would ask for cash. > > It's been around since 2005. > > Interesting that you criticize the monetary aspect of it, however...doesn't > GSOC provide, um, cash funding for the students chosen to work on the > projects? I was a GSoC mentor last year. The deal is more like a grant than a payment. And students can fail and not get paid. I had two students - one from India and one from Brazil. To me it was like "Programmers Without Borders", except I did not have to travel anywhere. It was hard work for all of us, but we had a lot of fun. Cheers, Ian W. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: How do I link with Aquaterm library for an external build?
On Jan 31, 2013, at 02:21, Jerry wrote: > On Jan 30, 2013, at 3:42 PM, Ryan Schmidt wrote: > >> If you want those three values to be in CFLAGS, you'll have to enclose them >> in quotes: >> >> CFLAGS="-F/opt/local/Library/Frameworks -framework AquaTerm" > > Thanks, Ryan. > > I entered this line with quotes in my script followed by > export CFLAGS > (and removed the symlink I mentioned earlier) but Aquaterm was not > found--PLplot still builds without the Aquaterm option. There are lots of > occurrences of things like this which I don't understand: > > cd /usr/local/plplot_build_dir/examples/c && /usr/bin/gcc > -F/opt/local/Library/Frameworks -framework AquaTerm > -I/Users/me/Documents/Programs/Ada/Code/Bindings/PLplot/plplot_svn/plplot/include > -I/usr/local/plplot_build_dir/include > -I/Users/me/Documents/Programs/Ada/Code/Bindings/PLplot/plplot_svn/plplot/lib/qsastime > -DUSINGDLL -o CMakeFiles/x33c.dir/x33c.c.o -c > /Users/me/Documents/Programs/Ada/Code/Bindings/PLplot/plplot_svn/plplot/examples/c/x33c.c > i686-apple-darwin11-llvm-gcc-4.2: -framework: linker input file unused > because linking not done > i686-apple-darwin11-llvm-gcc-4.2: AquaTerm: linker input file unused because > linking not done I'm not an expert on writing Makefiles or CMakeLists.txt; I tend to mostly package up software others have written that already have correctly-written build scripts. As far as I know, "-framework Foo" is to frameworks as "-lfoo" is to libraries, so it belongs in LDFLAGS and not CFLAGS. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Side effects?
* Ian Wadham [2013-01-31 14:34:06 +1100]: > BTW, does Macports have a nice safe GUI? > > Cheers, Ian W. My feeling is that Macports doesn't need a GUI. Using the command-line is part of the "fun". When I got my first Mac I spent literally all of my computing time on it using the Terminal. I bought some books specific to the UNIX subsystem of Mac OS X and that's the reason I became addicted to UNIX systems. If Apple ever decided to remove the access to the UNIX subsystem I'd stop using Mac's completely. Bit OT there, sorry :-) I can understand, though, why some people might find a Macports GUI helpful. But personally I'd never use it. -- Primary Key: 4096R/1D31DC38 2011-12-03 Key Fingerprint: A4B9 E875 A18C 6E11 F46D B788 BEE6 1251 1D31 DC38 ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: How do I link with Aquaterm library for an external build?
On Jan 30, 2013, at 3:42 PM, Ryan Schmidt wrote: > On Jan 30, 2013, at 15:50, Jerry wrote: > >> On Jan 30, 2013, at 3:04 AM, Mojca Miklavec wrote: >> >>> Please try to add "-F/opt/local/Frameworks" to CFLAGS >>> (CXXFLAGS/ObjCFLAGS/FFLAGS/FCFLAGS) and LDFLAGS in addition to >>> "-framework AquaTerm" and report whether it works. I don't have any >>> good idea how to make this work automatically (apart from introducing >>> pkg-config configuration). >>> >>> Apple automatically looks into /Library/Frameworks, but not into any >>> other place unless you provide an additional flag. > >> Your comment led me to put a symlink from >> /opt/local/Library/Frameworks/AquaTerm.framework to >> /Library/Frameworks/AquaTerm.framework. I'm not sure why I didn't think of >> that earlier but I was confused about the previous symlink in /usr/bin or >> whatever it was. > > Although this is probably not a problem for AquaTerm, because > /Library/Frameworks is a default search location, having more popular > libraries there can cause them to be opportunistically linked to. Which is > why we recommend you don't put anything in /Library/Frameworks (or > /usr/local) if you want to use MacPorts. > > >> I'm not a cmake expert and basically have to have most things that are >> cmake-related explained to me pretty literally. Since I've fixed the problem >> with the solution above, this is not terribly important for you to answer, >> but would you mind showing me more explicitly how to add >> "-F/opt/local/Frameworks" and "-framework AquaTerm" to CFLAGS? I currently >> have no CFLAGS variable in my build script. Would I add a line like this? >> >> CFLAGS=-F/opt/local/Frameworks -framework AquaTerm > > If you want those three values to be in CFLAGS, you'll have to enclose them > in quotes: > > CFLAGS="-F/opt/local/Library/Frameworks -framework AquaTerm" Thanks, Ryan. I entered this line with quotes in my script followed by export CFLAGS (and removed the symlink I mentioned earlier) but Aquaterm was not found--PLplot still builds without the Aquaterm option. There are lots of occurrences of things like this which I don't understand: cd /usr/local/plplot_build_dir/examples/c && /usr/bin/gcc -F/opt/local/Library/Frameworks -framework AquaTerm -I/Users/me/Documents/Programs/Ada/Code/Bindings/PLplot/plplot_svn/plplot/include -I/usr/local/plplot_build_dir/include -I/Users/me/Documents/Programs/Ada/Code/Bindings/PLplot/plplot_svn/plplot/lib/qsastime -DUSINGDLL -o CMakeFiles/x33c.dir/x33c.c.o -c /Users/me/Documents/Programs/Ada/Code/Bindings/PLplot/plplot_svn/plplot/examples/c/x33c.c i686-apple-darwin11-llvm-gcc-4.2: -framework: linker input file unused because linking not done i686-apple-darwin11-llvm-gcc-4.2: AquaTerm: linker input file unused because linking not done Jerry > >> Also, would adding /opt/local/Library/Frameworks/ to my PATH variable be >> useful? > > No; PATH is where you define the paths where programs that you run on the > command line are to be found; /opt/local/Library/Frameworks doesn't contain > programs; it contains frameworks. > ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
