kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 4/15/2012 11:08 AM, lajos kamocsay wrote:
> Thanks, Wayne. It might be a configuration cache issue. I'll rebuild it
> tonight when my real world project is done (bathroom tiling).

I've been there and done that!  Several times.  Have fun!

> 
> 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?

Not that I have found.  Generally I keep separate build configurations
around depending on what I am working on.  This is not a terribly
efficient use of disk space but it prevents the caching problem and I
know what to expect for each configuration.  Maybe some one else has a
better idea.

Wayne

> 
> Thanks-
> -lajos
> 
> On Apr 15, 2012 10:57 AM, "Wayne Stambaugh" <stambaughw@xxxxxxxxxxx
> <mailto: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
>     <mailto: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
>     <mailto: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
>     <mailto: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
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     Unsubscribe : https://launchpad.net/~kicad-developers
>     More help   : https://help.launchpad.net/ListHelp
>