Hey Eric, On Sat, Aug 18, 2007 at 11:17:16AM -0600, Eric Weddington wrote:
> Long time no see. :-) Surely it has been. :-) How's it going, buddy? > However, having said that, I understand that the above command will > resolve dependencies, such as avr-binutils and avr-gcc, and build > those too, correct? Yes, those things that are required to either build or run the port are identified as dependencies and then the ports infrastructure chases them down installs in the proper order. This is all done behind the scenes, the end user never needs to know what depends on what or what order things need to be built. The ports software takes care of it. > Is avrdude a dependency of avr-libc? > Is avr-gdb, or avr-insight, a dependency of avr-libc? > Is srecord a dependency of avr-libc? No, avrdude is not a dependcy of avr-libc, nor should it be. Similarly with the others. But one may say, well, those other tools are nice to have and maybe they should be installed. But Unix has the long standing tradition of leaving these decisions to their users. That said, if one were so inclinded, one could create a "meta-port". This is a port that does nothing itself, but rather just "depends" on several others. This is a way that you can put together multiple related tools and have them built and installed with one port target. So all the things in WinAVR could easily be made into a FreeBSD meta-port. Well, maybe not exactly - I don't know how much hand-tweaking you need to do for WinAVR. I'll say that it could be made into a meta-port - IF - it could be built and installed by building and installing a sequence of other independent ports. If you do a lot of custom stuff to make WinAVR aside from downloading and building from source the various packages, then that part may need to be handled in a special way. But the ports systems do allow for this by including pre- and post- hooks at various places in the ports infrastructure to do custom things. The point is, it needs to be able to be automated for it to mesh nicely into the ports system. > Does it come with additional documentation? That depends on the port. Typically ports take the project's source, use a set of configuration options that make sense, apply any patches necessary to build on the host system, and then build and install the software. These steps recurse for each dependency, until finally the port itself is processed. Most ports that have a number of options that can govern what is built and how, and it's really up to the end-user as to what they want. In this case the ports system will present an interactive menu to allow the user to select these features. That's the case unless the port is built with BATCH=YES in the environment in which case a set of reasonable defaults are selected and the port is built non-interactively. I almost always build BATCH=YES as I've rarely found that the defaults don't meet my needs. > Every OS has their own system, with their own set of users, > capabilities and assumptions. Windows users want one-stop-shopping > and that's what WinAVR provides. They don't want to think about the > packages they need or want. As with engineering, there's always > trade-offs. The trade-off with WinAVR is that it's all or nothing, > and it's not nice for the advanced user who wants to do more. True enough - my initial reply should definitely not be taken as a dig or anything against WinAVR, nor even Windows. It was only a statement that building and installing avr-gcc on FreeBSD is extremely, extremely simple. Even easier than installing WinAVR on Windows, IMO. > My personal preference is to have the best of both worlds, easy to > use for the beginner, but yet have the ability for the advanced user > to customize and dig deep to their hearts' content. Absolutely! And I'm not in any way even stating that Windows users are not advanced. Only that InstallShield-type canned installs provide little flexibility for doing special things, like working with the patches Joerg sent me. And advanced Windows user probably wouldn't have a problem with that either - they'd just go out and build from source, just like you do when you create a WinAVR release. But when they do that, they've left the InstallShield wizard world and have taken matters into their own hands, just like I was saying I do when I leave the ports/rpm path. In that case, they'll need to deal with all those little things like dependencies that crop up for themselves anyway, just like the rest of us, regardless of what OS they choose. But I would suggest that those things are easier to deal with on a Unix platform than Windows, certainly once you leave the beaten path and find yourself bushwhacking with a compass and wrinkled up map. :-) It's kind've funny - in the commercial software world, Windows rules. But in the open source software world, Unix rules. I think this is primarily due to the fact that Unix is an easy platform to develop for, nearly every Unix distribution comes with a complete and excellent set of development tools and documenation, and it has always nurtured a history of sharing from way back since its beginnings at AT&T so many decades ago. But I'm personally very happy that the tools work for the most part on the various popular platforms. I'm quite happy on my preferred platforms and am highly productive there. They are a natural fit for me based on my long-standing Unix development experience. I'm sure everyone else feels the same way regardless of what platform they call home. -Brian -- Brian Dean BDMICRO LLC http://www.bdmicro.com/ ATmega128 based MAVRIC controllers _______________________________________________ AVR-chat mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-chat
