kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 07/23/2012 05:05 AM, Carl Rash wrote:
> Why not handle it the way PDF Viewer and Text Editor are handled in KiCad


There are some terms that need to be defined to even complete this conversation, IMO. 

We'd have to distinguish between:

a) installation of pre-built binaries, and

b) build from source installations as possibly facilitated by Brians big CMake script, or
done manually.


Each is a conversation in and of itself.

Since b) involves compiling KiCad, and doing so with headers coming from Python, this begs
for treatment of python as if it were a build time library.  CMake was built to handle a
situation like this.  It is easy to tell CMake where a library is.

a) On the other hand, is "Windows Installer" specific.  (And I don't even know enough
about our Windows Installer policy to contribute to that half of the discussion.  After
all, poor Windows Installer & lack of package management is one reason I ran from Windows
over 10 years ago.)


But I think Miguel has enough now to work with however.  If he needs further help, I'm
sure he'll ask. There are some research items and some strategies for him to explore, and
I'm sure he'll come up with a good solution.

We talked the other day about categories and directories, and giving the user the control
over where scripts reside.  This impacts the UI experience fairly heavily.


Dick





>
> -----Original Message-----
> From: kicad-developers-bounces+crash=triad.rr.com@xxxxxxxxxxxxxxxxxxx
> [mailto:kicad-developers-bounces+crash=triad.rr.com@xxxxxxxxxxxxxxxxxxx] On
> Behalf Of Miguel Angel Ajo Pelayo
> Sent: Monday, July 23, 2012 1:50 AM
> To: Dick Hollenbeck
> Cc: kicad-developers@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Kicad-developers] Win32 compilation for kicad scripting
>
> an extra note, it seems that once you install Python in Win32, PYTHONPATH
> environment variable will point to it's installation.
>
> 2012/7/23 Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>:
>> 2012/7/23 Dick Hollenbeck <dick@xxxxxxxxxxx>:
>>>> that some minimal form of Python could be included in KiCad installer.
>>> of Python could be included in KiCad installer.
>>>
>>>
>>> ?? Why then, not just install Linux when installing Kicad?, (you 
>>> know, take the Windows user out of his misery once and for all.) Or 
>>> option 2, make the misery so bad, that the he has to install Linux 
>>> himself, just to make the pain stop, by adding a second, third, or fourth
> copy of Python to his system?
>>> ?? Why then, not just install Linux when installing Kicad?, (you 
>>> know, take the Windows user out of his misery once and for all.) Or 
>>> option 2, make the misery so bad, that the he has to install Linux 
>>> himself, just to make the pain stop, by adding a second, third, or fourth
> copy of Python to his system?
>> Hahaha, good point Dick, anyway, somehow, in Win32 is a common 
>> practice to include the python interpreter in many softwares that 
>> depend on python, at least the DLL (see point b)
>>
>> Anyway, my preferences are:
>>
>> a) Ask the users to install Python 2.7.x, and set it on system PATH as 
>> a prerequisite, if it's not satisfied during installation just give a
>> link to: [http://www.python.org/getit/], it's just 15MB   [apt-get
>> does that automatically in Linux]
>>
>> b) Bundle the whole Python exe + Python.dll + python basic set of 
>> system libraries,
>>
>> c) Bundle only the Python.dll + python basic set of system libraries,
>>
>> d) Statically link Python in kicad + provide the basic set of python 
>> system libraries [a good way of wasting system memory]
>>
>> --jokes--
>>
>> e) forcing the users install Linux would save a lot of time, yes, but, 
>> poor Win32 and Mac users ;)
>>
>> f) Installing Linux itself [KicadOS!!!, hahaha]
>>
>>
>>
>> I think that a is better than b,c (even though it needs more user
>> interaction) because the user will have all the system-wide available 
>> python modules and libraries, and also kicad functionality will stay 
>> available to any other python scripts on the Win32 systems.
>>
>>
>> Anyway, we might take a look to what other Win32 softwares are doing 
>> regarding this, and think.
>>
>>
>>> Here I thought that when I run
>>>
>>>   $ ccmake .
>>>
>>> on linux, I was doing something that everyone could do, which is to 
>>> specify where things are located.  Apparently not everyone on Windows can
> be expected to do this.
>> It's not easy even for a developer, since you need to download cmake, 
>> wx, mingw gcc, etc separately by yourself. Win32 it's not fun for 
>> developers :)
>>
>>> Then, when we support Javascript and lua, we should install those in
> advance as part of the installer too?
>>
>> For Lua you must link it to your executable (last time I used it had 
>> no dll or dynamically loadable modules -may be I'm wrong here-), the 
>> advantage of lua is that it's tiny (<128kB), the disadvantage is that 
>> it doesn't have the broad base of libraries that Python does.
>>
>> For Javascript (v8), we have loadable libraries, we might be in the 
>> same case as Python.
>>
>>
>> --
>>
>> Miguel Angel Ajo Pelayo
>> http://www.nbee.es
>> +34 636 52 25 69
>> skype: ajoajoajo
>
>