Re: [avr-chat] Can't Install avr-gcc in FreeBSD

[Brian Dean]

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