kicad-developers team mailing list archive

[lajos kamocsay <panka.nospam@xxxxxxxxx>]

Hi Wayne-

I deleted the build directory, compiled from scratch and now the issue is
gone. So it must have been a cmake cache problem as you suspected. Lesson
learned ;)

Thanks
Lajos
On Apr 15, 2012 11:21 AM, "Wayne Stambaugh" <stambaughw@xxxxxxxxxxx> wrote:

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