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" <stambau...@verizon.net> 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" <stambau...@verizon.net > > <mailto: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 > > <mailto: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 > > <mailto: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 > > <mailto: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 > > <mailto: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