On 01/28/2015 01:45 AM, jp charras wrote:
Le 28/01/2015 08:07, Bernhard Stegmaier a écrit :
Again, I am open for all reasonable suggestions for the path itself, this is
not the discussion here.
The only thing I want to say is that the install prefix concept in my opinion
is just a unix thing
Hi folks,
>From a packaging perspective, and the perspective of getting this good code
Wayne wrote in the codebase, I say let's go with
GetOSXKicadMachineDataDir(). It matches the rest of the OS X work Bernhard
and I and everyone else have been doing for months and months.
All these search path
OK... then, for now just simply setting the base to a fixed/hardcoded
/Library/Application Support/kicad
will probably do the trick for OSX and at least should be consistent to
what we have at the moment spread over various spots in the code.
You could do that without any CMake magic directly i
On 1/28/2015 2:42 AM, Fat-Zer wrote:
> By the word, are there any arguments for using env vars rather than a
> configuration file to store the paths?
Cross platform path incompatibilities (fp-lib-table would not be cross
platform compatible with stored paths) and development purposes (allows
devel
On 1/28/2015 2:07 AM, Bernhard Stegmaier wrote:
> Again, I am open for all reasonable suggestions for the path itself, this is
> not the discussion here.
Correct. We've turned this discussion into way more than I had
intended. The discussion should be what is the best *default* path
(most commo
Le 28/01/2015 08:07, Bernhard Stegmaier a écrit :
> Again, I am open for all reasonable suggestions for the path itself, this is
> not the discussion here.
>
> The only thing I want to say is that the install prefix concept in my opinion
> is just a unix thing which comes from compiling applicat
By the word, are there any arguments for using env vars rather than a
configuration file to store the paths?
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~
Again, I am open for all reasonable suggestions for the path itself, this is
not the discussion here.
The only thing I want to say is that the install prefix concept in my opinion
is just a unix thing which comes from compiling applications yourself… so, in
my opinion you could say Linux is the
I would vote for a location that keeps KiCad things 'together' in the
hope that everything could be on a flash drive which could be runable
when it is plugged into a Mac - which has appropriate homebrew and
generic applications and libraries. There does need to be a decision
about what is uniqu
On 1/27/2015 6:06 PM, Bernhard Stegmaier wrote:
> Well, in fact I think it also isn’t really so much different on Windows.
> Where would you put general data similar to /usr/share on linux there?
Yes. I changed the default locations for all of the libraries to be
installed in ${CMAKE_PREFIX_PATH}
On 1/27/2015 5:41 PM, Adam Wolf wrote:
> I think Bernhard is on track here.
>
> Reiterating, for OS X, for us, for now, /usr/local/share is
> /Library/Application Support/
Is /Library/Application Support/ an absolute path. If so, then that's
probably the correct default value for OSX.
>
> Thi
On 1/27/2015 5:36 PM, Bernhard Stegmaier wrote:
>
> On 27.01.2015, at 21:20, Wayne Stambaugh wrote:
>
>> On 1/27/2015 2:57 PM, Bernhard Stegmaier wrote:
>>>
>>> CMAKE_INSTALL_PREFIX is of course defined when building on OS X, it is the
>>> folder where the app bundle will be stored.
>>
>> Is th
Well, in fact I think it also isn’t really so much different on Windows.
Where would you put general data similar to /usr/share on linux there?
Maybe in the “My documents” folder of “All users” (or whatever it is called) -
or maybe one of the other application data folders that Windows has (those
I think Bernhard is on track here.
Reiterating, for OS X, for us, for now, /usr/local/share is
/Library/Application Support/
This isn't perfect, and there's reason to change it, maybe, but it's some
place the OS X devs and vocal users on the dev list mostly agree on :)
When I have been working o
On 27.01.2015, at 21:20, Wayne Stambaugh wrote:
> On 1/27/2015 2:57 PM, Bernhard Stegmaier wrote:
>>
>> CMAKE_INSTALL_PREFIX is of course defined when building on OS X, it is the
>> folder where the app bundle will be stored.
>
> Is this not the path where the libraries are installed? By def
On 1/27/2015 2:57 PM, Bernhard Stegmaier wrote:
> Hi Wayne,
>
> I had a look at the patch and I currently see a small issue on OS X (maybe
> not only being OS X specific…).
>
> The definition of the data path is as follows in config.h.make:
>/// The install prefex used for KiCad's libraries.
Hi Wayne,
I had a look at the patch and I currently see a small issue on OS X (maybe not
only being OS X specific…).
The definition of the data path is as follows in config.h.make:
/// The install prefex used for KiCad's libraries.
#define KICAD_DATA_PATH "@CMAKE_INSTALL_PR
No hurry Bernhard. Whenever you get a chance. I just want to have a
complete solution before I commit the changes.
Thanks,
Wayne
On 1/25/2015 2:22 PM, Bernhard Stegmaier wrote:
> Hi Wayne,
>
> I’ll try to look at it starting tomorrow, so I hope I can give feedback
> until mid of the week.
>
2015-01-25 20:02 GMT+01:00 Wayne Stambaugh :
> On 1/25/2015 10:29 AM, Nick Østergaard wrote:
>> 2015-01-23 14:42 GMT+01:00 Wayne Stambaugh :
>>> As you all know, we have had many users struggle with setting up the
>>> environment variables used in the footprint library table and 3D model
>>> code.
Hi Wayne,
I’ll try to look at it starting tomorrow, so I hope I can give feedback until
mid of the week.
Regards,
Bernhard
On 25.01.2015, at 20:02, Wayne Stambaugh wrote:
> On 1/25/2015 10:29 AM, Nick Østergaard wrote:
>> 2015-01-23 14:42 GMT+01:00 Wayne Stambaugh :
>>> As you all know, we h
On 1/25/2015 10:29 AM, Nick Østergaard wrote:
> 2015-01-23 14:42 GMT+01:00 Wayne Stambaugh :
>> As you all know, we have had many users struggle with setting up the
>> environment variables used in the footprint library table and 3D model
>> code. The attached patch sets the process environment va
2015-01-23 14:42 GMT+01:00 Wayne Stambaugh :
> As you all know, we have had many users struggle with setting up the
> environment variables used in the footprint library table and 3D model
> code. The attached patch sets the process environment variables
> KIGITHUB and KISYS3DMOD. KIGITHUB should
Great work. I am traveling today and will be unable to test promptly.
Adam Wolf
On Fri, Jan 23, 2015 at 7:42 AM, Wayne Stambaugh
wrote:
> As you all know, we have had many users struggle with setting up the
> environment variables used in the footprint library table and 3D model
> code. The a
As you all know, we have had many users struggle with setting up the
environment variables used in the footprint library table and 3D model
code. The attached patch sets the process environment variables
KIGITHUB and KISYS3DMOD. KIGITHUB should work for all platforms since
it is the URL for the k
24 matches
Mail list logo
