kicad-developers team mailing list archive

["llamatronique" <llamatronique@...>]

Sorry for the confusion - both patches were submitted by me.

The second undid a few lines little of the first, but only because
once I started debugging, it became clear the original mac support
hadn't treated the Mac as a 'unix' platform which it is, although the
notion of application bundles is different from the usual unix layout
and that's what the changes focused on.

Wherever I make changes specifically for the mac, they will always be
done in such a way as to not affect other builds. If I submit a patch
which fixes anything generally I'll make it clear that it affects all
builds.

Cheers,
Simon

--- In kicad-devel@xxxxxxxxxxxxxxx, Geoff Harland <gharlandau@...> wrote:
>
> Thank you for responding to my previous message. Since the time that
I sent that, I have recompiled the source code for Linux and
encountered no problems at the time, and as far as I am aware (after
starting each of the applications), the updated code has not broken
anything.
> 
> I will recheck the updated source code in the very near future, but
at the time that I had been looking at it and editing it previously,
the changes concerned only affected Mac builds, and did not have any
impact upon either the Windows or Linux builds (or at least no
significant impact).
> 
> And for at least the time being, I will refrain from committing any
associated changes.
> 
> Regards,
> Geoff Harland.
> 
> 
> Dick Hollenbeck wrote:
> 
> > I am confused about at least one of these changes, and I share your
> > concern that there should be a qualified Mac guy to maintain the MAC
> > stuff. Plus it seems the definition of "MAC" is not stable or defined.
> > 
> > For example, less than 5 days ago I added a patch for a MAC guy
and now
> > this guy wants to undo it, see file
> > eeschema/plugins/netlist_form_pads-pcb.cpp. That patch removes
> > precisely what another guy asked me to add.
> > 
> > So they have us going in circles it seems.
> > 
> > We could simply add a svn tree directory under trunk, called
> > pending_patches, and put stuff there until somebody can go through
> > them. This patch effects so many files that one could argue that it
> > should be split into separate patches.
> > 
> > If we go the pending_patches route, you would have to invent a
> > consistent file extension name for these patches. Give it some
> > thought. Frankly I would not expect much more feedback than what you
> > are getting from me.
> > 
> > Frankly I don't care about the MAC specific patches, but I get nervous
> > about the part of this huge patch file that does effect the linux and
> > windows platforms, so maybe a patch split on that basis would give
> > somebody that is a MAC builder the ability to apply a clean MAC
specific
> > patch at any time in the future, providing it is maintained in the
> > trunk/pending_patches directory in the repository. The part of the
> > patch effecting everyone could be scrutinized now.
> > 
> > This strategy keeps us from running in circles.
> > 
> > Dick
> 
> 
>      
____________________________________________________________________________________
> Sick of deleting your inbox? Yahoo!7 Mail has free unlimited storage.
> http://au.docs.yahoo.com/mail/unlimitedstorage.html
>