kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #02049
Re: Re: New coding guidelines.
-
To:
kicad-devel@xxxxxxxxxxxxxxx
-
From:
Wayne Stambaugh <stambaughw@...>
-
Date:
Fri, 02 Jan 2009 11:49:00 -0500
-
In-reply-to:
<495DA226.8050202@...>
-
User-agent:
Thunderbird 2.0.0.19 (Windows/20081209)
Dick Hollenbeck wrote:
> wafeliron wrote:
>> For example its hard to
>> find the hardcoded paths in the source and this is a real LACK if i
>> install on linux and dont want to but it in the root directory. I
>> would like to work on it but its not well commented and structured
>> into files about reading the .KiCad .pcbnew files ...
>>
>
>
> I agree that the linux install could be improved. I would like the
> installed data tree to be separate from the code tree, optionally.
>
>
> I would like to be able to put the code in /opt/kicad or
> /home/dick/kicad and cannot do that now. And I would like to put the
> data tree in /home/dick/kicaddata for example.
>
>
> CMake would need to spit out some C++ code containing the selected paths
> and then that would be used instead of the hard coded paths in gestfiche.cpp
>
>
> There may be ways, but this seems workable to me.
Using relative paths may be an usable if not a particularly elegant
solution. The CMake default installs files using the typical (if there
is actually such a thing as typical) Linux file system hierarchy where
executables are installed in /bin and data and doc files are installed
in share/kicad/ relative to CMAKE_INSTALL_PREFIX. Even running "make
install" in Windows will preserve this heirarchy albeit typically under
"c:\Program Files\Kicad". If you don't deviate from this pattern you
can always find the data and doc files relative the executable path.
This has the advantage of being able to install development versions in
a non-standard path for debugging purposes.
Wayne
>
>
> Dick
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>
Follow ups
References