kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #00498
Re: Re:Path & execution fixes for Mac OS
--0-1575000123-1188194250=:37688 Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
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 probl=
ems at the time, and as far as I am aware (after starting each of the appli=
cations), 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 c=
oncerned 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 associa=
ted 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.
>=20
> 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.
>=20
> So they have us going in circles it seems.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> This strategy keeps us from running in circles.
>=20
> Dick
_____________________________________________________________________=
_______________
Sick of deleting your inbox? Yahoo!7 Mail has free unlimited storage.
http://au.docs.yahoo.com/mail/unlimitedstorage.html
--0-1575000123-1188194250=:37688 Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman, new york, times, serif;=
font-size:12pt"><DIV>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 start=
ing each of the applications), the updated code has not broken anything.</D=
IV>
<DIV> </DIV>
<DIV>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 chan=
ges concerned only affected Mac builds, and did not have any impact upon ei=
ther the Windows or Linux builds (or at least no significant impact).</DIV>
<DIV> </DIV>
<DIV>And for at least the time being, I will refrain from committing any as=
sociated changes.</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Geoff Harland.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Dick Hollenbeck wrote:</DIV>
<DIV> </DIV>
<DIV>
<DIV class=3Dmsgarea>> I am confused about at least one of these changes=
, and I share your<BR>> concern that there should be a qualified Mac guy=
to maintain the MAC<BR>> stuff. Plus it seems the definition of "MAC" i=
s not stable or defined.<BR>> <BR>> For example, less than 5 days ago=
I added a patch for a MAC guy and now<BR>> this guy wants to undo it, s=
ee file<BR>> eeschema/plugins/netlist_form_pads-pcb.cpp. That patch remo=
ves<BR>> precisely what another guy asked me to add.<BR>> <BR>> So=
they have us going in circles it seems.<BR>> <BR>> We could simply a=
dd a svn tree directory under trunk, called<BR>> pending_patches, and pu=
t stuff there until somebody can go through<BR>> them. This patch effect=
s so many files that one could argue that it<BR>> should be split into s=
eparate patches.<BR>> <BR>> If we go the pending_patches route, you w=
ould have to invent a<BR>> consistent file extension name for these
patches. Give it some<BR>> thought. Frankly I would not expect much mor=
e feedback than what you<BR>> are getting from me.<BR>> <BR>> Fran=
kly I don't care about the MAC specific patches, but I get nervous<BR>> =
about the part of this huge patch file that does effect the linux and<BR>&g=
t; windows platforms, so maybe a patch split on that basis would give<BR>&g=
t; somebody that is a MAC builder the ability to apply a clean MAC specific=
<BR>> patch at any time in the future, providing it is maintained in the=
<BR>> trunk/pending_patches directory in the repository. The part of the=
<BR>> patch effecting everyone could be scrutinized now.<BR>> <BR>>=
; This strategy keeps us from running in circles.<BR>> <BR>> Dick<BR>=
</DIV></DIV></div><br>
<hr size=3D1>
Get the World's number 1 free email service. <a href=3D"http://au.rd.yahoo.=
com/mail/taglines/optusnet/number_one/*http://mail.yahoo.com.au"; target=3D_=
blank>Find out more</a>.
</body></html> --0-1575000123-1188194250=:37688--
Follow ups
