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" <stambau...@verizon.net> 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 <d...@softplc.com> > 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@lists.launchpad.net > >> Unsubscribe : https://launchpad.net/~kicad-developers > >> More help : https://help.launchpad.net/ListHelp > >> > >> > >> _______________________________________________ > >> Mailing list: https://launchpad.net/~kicad-developers > >> Post to : kicad-developers@lists.launchpad.net > >> Unsubscribe : https://launchpad.net/~kicad-developers > >> More help : https://help.launchpad.net/ListHelp > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp