I use all three names without much care, Mac OSX, OSX, Mac OS, but I think
you're right.
I checked, and it's implemented using gettimeofday :-)
ajo$ otool -t -I -v -V getrunningmicrosecs.cpp.o
getrunningmicrosecs.cpp.o:
(__TEXT,__text) section
__Z19GetRunningMicroSecsv:
On 01/12/2013 06:05 PM, Miguel Angel Ajo Pelayo wrote:
> Where is it included exactly?, after pulling head now it fails on MacOS:
>
> Linking CXX shared module _pcbnew.so
> ld: library not found for -lrt
No -lrt on MacOS?
I wonder how common/GetRunningMicroSecs() gets implemented on MacOS?
get
I will commit this fix shortly.
Dick
> Where is it included exactly?, after pulling head now it fails on MacOS:
>
> Linking CXX shared module _pcbnew.so
> ld: library not found for -lrt
>
> can we add an "if NOT WIN32 AND NOT APPLE" for the -lrt inclusion ?
Yes, the PCBNEW_EXTRA_LIBS
is the s
On 13/01/2013, at 01:16, Miguel Angel Ajo Pelayo wrote:
> I will pull head again, and include the "const" fix that makes clang compiler
> happier.
Wow, you did it already.
> Thanks for your time too Dick, and Heikki, thanks for your patch, this work
> it's something the normal
> users won'
Hehe, no problem, It would be great to find a way of fixing that dependency
problems automatically,
they keep me head-scratching with problems like this from time to time.
I will pull head again, and include the "const" fix that makes clang compiler
happier.
Thanks for your time too Dick, and
Committed this patch in 3901.
Thanks Heikki
Miguel, sorry to waste your time. A preceding "make clean" would have avoided
that confusion.
Thanks for your time however.
Dick
___
Mailing list: https://launchpad.net/~kicad-developers
Post to :
Where is it included exactly?, after pulling head now it fails on MacOS:
Linking CXX shared module _pcbnew.so
ld: library not found for -lrt
can we add an "if NOT WIN32 AND NOT APPLE" for the -lrt inclusion ?
Greetings! :-)
Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo
On
I found what happens, it's no real problem with the patch, but with the
dependency identification from swig .i files to class_track.h ,
dependencies are set manually now because cmake cannot determine that the
.i file depends on class_track.h and that pcbnew_wrap.cxx and
scripting/pcbnewPYTHON_wrap
On 01/12/2013 11:15 AM, Wayne Stambaugh wrote:
> I've been attempting to resolve my Python scripting build issues on
> MinGW32 on Windows and I have a few questions for the folks who wrote
> the cmake build code. Why are we not using cmake's FindPythonInterp()
> instead of specifying the python
>
> From: jp charras
>To: kicad-developers@lists.launchpad.net
>Sent: Saturday, January 12, 2013 10:59 PM
>Subject: Re: [Kicad-developers] [Bug] WRL import broken
>
>Le 11/01/2013 21:41, Cirilo Bernardo a écrit :
>>>
>>> From: Хоте
Sorry, I replied Wayne only.
I will review my coding style for cmake files too before any next commits.
Sorry about that.
Enviado desde un móvil
Inicio del mensaje reenviado:
> De: Miguel Angel
> Fecha: 12 de enero de 2013 21:05:16 GMT+01:00
> Para: Wayne Stambaugh
> Asunto: Re: [Kicad-deve
I've been attempting to resolve my Python scripting build issues on
MinGW32 on Windows and I have a few questions for the folks who wrote
the cmake build code. Why are we not using cmake's FindPythonInterp()
instead of specifying the python executable on the path? Specifying the
Python interp
Le 11/01/2013 21:41, Cirilo Bernardo a écrit :
From: Хотеев Сергей
To: kicad-developers@lists.launchpad.net
Sent: Saturday, January 12, 2013 4:39 AM
Subject: [Kicad-developers] [Bug] WRL import broken
Hi
In 2010 , FreeCAD forum (
http://sourceforge.net/apps/p
Le 03/01/2013 18:08, Georg Gast a écrit :
Hi,
i made some 3d models with openscad and converted them via meshconv to
wrl , but i had some difficulites because the format is a little
different in organization. Group/Def and some other tags. It's hard
for the user to determine why kicad dont sh
14 matches
Mail list logo
