kicad-developers team mailing list archive

[lajos kamocsay <panka.nospam@xxxxxxxxx>]

Thanks, Wayne. It might be a configuration cache issue. I'll rebuild it
tonight when my real world project is done (bathroom tiling).

In general I find the cmake caching very frustrating. The only reliable way
I found to make sure that the configuration's correct is to delete the
whole build folder and rebuild from scratch. Or is there a better way?

Thanks-
-lajos
 On Apr 15, 2012 10:57 AM, "Wayne Stambaugh" <stambaughw@xxxxxxxxxxx> wrote:

> On 4/14/2012 11:18 PM, lajos kamocsay wrote:
> > Hi-
> >
> >
> > When I build revno 3511, the tracks that I draw in pcbnew are huge
> > (wider than the default page) (screenshot attached).
> > I use these flags for cmake:
> >
> > cmake ../kicad.latest -DKICAD_STABLE_VERSION=ON
> -DCMAKE_BUILD_TYPE=Release \
> >       -DCMAKE_INSTALL_PREFIX=/usr
> >
> > Am I missing a flag? Or is this just a temporary bug?
>
> It could be.  Are you sure that USE_PCBNEW_NANOMETRES=OFF in your
> CMakeCache.txt?  If USE_PCBNEW_NANOMETRES=ON, than you should expect
> some object and units scaling to be broken.  I have already fixed the
> page reference and title block, grid, and zoom scaling for nanometers in
> my development branch which I hope to commit some time today.
>
> FYI when building the testing branch, use -DKICAD_TESTING_VERSION=ON.  I
> believe -DKICAD_STABLE_VERSION=0N should only be used when building the
> stable branch of KiCad.  Although that shouldn't effect the Pcbnew
> internal units.
>
> I cannot duplicate this problem so it may be a build configurations issue.
>
> Wayne
>
> >
> >
> > Thanks-
> > -lajos
> >
> >
> >
> > On Fri, Apr 13, 2012 at 1:42 PM, Dick Hollenbeck <dick@xxxxxxxxxxx>
> wrote:
> >> On 04/13/2012 10:18 AM, Wayne Stambaugh wrote:
> >>> On 4/13/2012 8:39 AM, Dick Hollenbeck wrote:
> >>>> On 04/13/2012 02:04 AM, jean-pierre charras wrote:
> >>>>> Le 12/04/2012 20:53, Wayne Stambaugh a écrit :
> >>>>>> On 4/12/2012 9:05 AM, Dick Hollenbeck wrote:
> >>>>>>> On 04/11/2012 06:41 PM, Dan Chianucci wrote:
> >>>>>>>> This new format looks great, I have a few comments/questions
> >>>>>>>>
> >>>>>>>>       1) in some spots like module pads there is (net<nutNum>
>  <netName>) and in other
> >>>>>>>> spots like track segments it only has (net<netNum>).
> >>>>>>>>       2)What do the edge tags represent in the Module
> >>>>>>> Exactly.  It might not be the first English tag that comes to mind
> for this. eh?  I'm not
> >>>>>>> even sure these are limited to "edges".
> >>>>>> This is one of those areas where I am relying on the knowledge of
> >>>>>> someone who know about the BOARD_ITEM internals that I do.  If
> there is
> >>>>>> a more descriptive name or way to present this information, I am
> >>>>>> certainly open to suggestion.
> >>>>>>
> >>>>>>>>       3)Draw arc has tags start and end.  I'm not sure if this
> has changed, but the file
> >>>>>>>> format before this held onto the center of the arc, and an
> endpoint of the arc...
> >>>>>>>>          The file format definitions also say it holds onto the
> starting point and the
> >>>>>>>> ending point, which caused a lot of headaches when I wrote my
> file format converter
> >>>>>> I've saved the object information as defined in the current file
> format
> >>>>>> document as closely as possible.  If arcs are defined this way in
> >>>>>> current file format, then they will be defined that way in the new
> file
> >>>>>> format.  Otherwise, some transformation will have to be made when
> >>>>>> reading the file.
> >>>>>>
> >>>>>>>>       4) What are the two (at) tags in module_text for? why not
> only 1
> >>>>>>>>                Is one a position relative to the module and one a
> position relative to
> >>>>>>>> the board?
> >>>>>> Good question.  It appears that TEXTE_MODULE::m_Pos0 which is
> relative
> >>>>>> to the anchor position of the module is the only position saved in
> the
> >>>>>> current format and EDA_TEXT::m_Pos is the absolute position on the
> board
> >>>>>> which I'm guessing is determined from the position of the module.
>  I'm
> >>>>>> not sure why it was done this way.  Is there any reason not to dump
> >>>>>> TEXTE_MODULE::m_Pos0 and just use EDA_TEXT::m_Pos?
> >>>>> All items inside a MODULE have a position on board (m_Pos, m_Start
> ...
> >>>>> and the corresponding parameter relative to the module anchor.
> >>>>> The reason is m_Pos *should always* be calculated from m_Pos0 after
> a rotation transform,
> >>>>> due to rounding issues.
> >>>>> Only 90 degrees rotations do not have rounding issues.
> >>>>> Therefore, after some rotations (for instance 10 rotations each for
> 9 degrees),
> >>>>> when using only m_Pos, there is a significant error between one 90
> deg rotation
> >>>>> and 10 x 9 deg rotations.
> >>>>>
> >>>>> Because absolute coordinates are calculated from relative
> coordinates,
> >>>>> only relative coordinates need to be saved on files.
> >>>>> (absolute position and rotation of the MODULE are known)
> >>>>>
> >>>>> I have not a strong opinion about how flipped footprints should
> store relative coordinates,
> >>>>> but I am thinking the stored values (coordinates, text mirroring,
> layers and layer masks) could be
> >>>>> stored as non flipped values, i.e. a flipped footprint is
> "un-flipped", saved and flipped (restored).
> >>>>> Actual values will be restored after reading the file.
> >>>>>
> >>>>> Eeschema stores (in lib) shapes in position 0, orientation/mirroring
> 0,
> >>>>> and stores the geometric transform for each component.
> >>>>>
> >>>>> This is perhaps not a bad idea to do the same in Pcbnew.
> >>>>>
> >>>>> Some other files format use the same thing,
> >>>>> and this could make file format conversion more easy.
> >>>>
> >>>>
> >>>> We seem to have no extraneous C++ objects.  And this conversation
> should not diverge into
> >>>> changing C++ objects, but should remain largely focused on file
> format.
> >>>>
> >>>>
> >>>> However, I will not let go of the importance of this format's effect
> on our ability to
> >>>> perform clipboard operations later.  From day one going back 4-5
> years ago, this has
> >>>> always been a main objective of the s-expression format of mine.
> >>>>
> >>>>
> >>>> Within a BOARD C++ object, there are two kinds of text C++ objects,
> two kinds of line C++
> >>>> objects, two kinds of arc objects, etc, with one relative to the
> board and one relative to
> >>>> the module/footprint.  This is status quo.
> >>>>
> >>>>
> >>>> We need:
> >>>>
> >>>>
> >>>> 1) to differentiate these later when pulling them off the clipboard,
> >>>> 2) to create different C++ objects at file load and at clipboard
> parsing time.
> >>>> 3) to augment them with different trailing s-expression elements.
> >>>>
> >>>>
> >>>> So I suggest:
> >>>>
> >>>> pcb_text, pcb_line, pcb_arc, pcb_circle, pcb_poly
> >>>>
> >>>>
> >>>> fp_text, fp_line, fp_arc, fp_circle, fp_poly
> >>> Sounds reasonable.  I'm assuming fp is short for footprint.  If we drop
> >>> the module prefix from the file format, I think we should internally
> >>> rename all things MODULE to FOOTPRINT for the same symmetry reasoning.
> >>> This gives developers a clearer understanding between the file format
> >>> and the objects they are related to.  If we keep module concept in
> >>> source code and footprint in the file format, that will just add to the
> >>> confusion.  A simple global search and replace can resolve this issue.
> >>> If no one objects, I'll go ahead and rename the board objects when I
> >>> change the s-expression token for these objects.
> >>>
> >>> Wayne
> >>
> >>
> >> I agree that what we have is a footprint, i.e. class MODULE is better
> named FOOTPRINT.
> >>
> >> However, I think that although renaming the class MODULE to FOOTPRINT
> might be easy,
> >> renaming all the automatic variables which are spelled "module" and
> "Module", and keeping
> >> them separated from other comments, is not easy.  Then one asks, how
> helpful is this if we
> >> have class FOOTPRINT, but variables named "module"?
> >>
> >>
> >> I would not be in favor of having class FOOTPRINT with variables named
> "module" and "Module".
> >>
> >>
> >> Agreed, what we have looks like footprints to me.
> >>
> >> At some point in the future, what would a genuine module look like?
> >>
> >> A "module" could be a fragment of a BOARD consisting of a number of
> footprints and tracks.
> >>
> >> This is good homework for my grandkids, because that's about the time
> it would get done, IMO.
> >>
> >> Until then, what we have looks like footprints, but I could be blind
> and not know it.
> >>
> >> Do you want to rename both variables and the class name?  If not, then
> maybe wait until we
> >> have actual modules, and simply comment the class header with this
> information.
> >>
> >>
> >> All or none is my suggestion.  The compiler won't care, and you
> probably won't after the
> >> PCB_IO class is done.
> >>
> >> Where it is more important is in the UI, consisting of dialogs and
> documentation.
> >>
> >>
> >> Dick
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> >>
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>