* Dmitry Marakasov (amdmi3@hades.panopticon) wrote:
> Anyway for now, I did some research and solved the problem of inplace
> vs. systemwide compilation in a way that I find acceptable.
>
> I check for CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT to basically
> know whether a user has explicitly
> > I.e. it could be replaced with a string of the same length or a
> > shorter one, but not a longer one.
> >
> > CMake works around this by extending the build RPATH artificially with
> > ":" at the end I think, patchelf works around this by making the whole
> > executable one page bigger if
On 03-Dec-15 16:59, Johannes Zarl-Zierl wrote:
I.e. it could be replaced with a string of the same length or a
shorter one, but not a longer one.
CMake works around this by extending the build RPATH artificially with
":" at the end I think, patchelf works around this by making the whole
On Thursday, December 03, 2015 09:27:29 Ruslan Baratov via CMake
wrote:
> On 03-Dec-15 04:34, Alexander Neundorf wrote:
> > On Wednesday, December 02, 2015 12:27:42 Ruslan Baratov wrote:
> > If RPATH was _designed_ to be patchable, tools could just do it,
> > instead of having to implement
On 04-Dec-15 03:47, Alexander Neundorf wrote:
On Thursday, December 03, 2015 09:27:29 Ruslan Baratov via CMake wrote:
> On 03-Dec-15 04:34, Alexander Neundorf wrote:
> > On Wednesday, December 02, 2015 12:27:42 Ruslan Baratov wrote:
> > If RPATH was _designed_ to be patchable, tools could
On Wednesday, December 02, 2015 12:27:42 Ruslan Baratov wrote:
> On 02-Dec-15 05:13, Alexander Neundorf wrote:
...
> > well, the RPATH entry was not designed to be patched,
>
> RPATH designed to be patched. And since it's a third time I'm making
> this statement please provide any arguments if
On 30/11/2015 02:10, Dmitry Marakasov wrote:
Hi!
This question bugs me for a long time so I though maybe someone has
a solution. I have a project which includes an application and some
data for it. An application needs to know path to its data files, so
I pass it via compiler definition:
On 03-Dec-15 04:34, Alexander Neundorf wrote:
On Wednesday, December 02, 2015 12:27:42 Ruslan Baratov wrote:
> On 02-Dec-15 05:13, Alexander Neundorf wrote:
...
> > well, the RPATH entry was not designed to be patched,
>
> RPATH designed to be patched. And since it's a third time I'm
On Tuesday, December 01, 2015 07:17:35 Ruslan Baratov wrote:
> On 01-Dec-15 03:51, Alexander Neundorf wrote:
> > On Monday, November 30, 2015 16:13:03 Ruslan Baratov via CMake
wrote:
> > > On 30-Nov-15 09:10, Dmitry Marakasov wrote:
> > > > Hi!
> >
> > ...
> >
> > > > The best solution would be
On 02-Dec-15 05:13, Alexander Neundorf wrote:
On Tuesday, December 01, 2015 07:17:35 Ruslan Baratov wrote:
> On 01-Dec-15 03:51, Alexander Neundorf wrote:
> > On Monday, November 30, 2015 16:13:03 Ruslan Baratov via CMake wrote:
> > > On 30-Nov-15 09:10, Dmitry Marakasov wrote:
> > > > Hi!
On 02-Dec-15 12:27, Ruslan Baratov via CMake wrote:
If you pass "/usr/local" output will be (nice):
--
/usr/local
--
If you pass "/home/username", output will be (nice):
/home/username
If you pass
On Monday, November 30, 2015 16:13:03 Ruslan Baratov via CMake
wrote:
> On 30-Nov-15 09:10, Dmitry Marakasov wrote:
> > Hi!
> >
...
> > The best solution would be for cmake to fix path in executable file
> > right after installation, something similar to what cmake does with
> > rpaths.
>
> I
On 01-Dec-15 03:51, Alexander Neundorf wrote:
On Monday, November 30, 2015 16:13:03 Ruslan Baratov via CMake wrote:
> On 30-Nov-15 09:10, Dmitry Marakasov wrote:
> > Hi!
> >
...
> > The best solution would be for cmake to fix path in executable file
> > right after installation, something
would be totally non-portable to
Windows.
--
Daniel Schepler
From: CMake [cmake-boun...@cmake.org] on behalf of Dmitry Marakasov
[amd...@amdmi3.ru]
Sent: Sunday, November 29, 2015 6:10 PM
To: cmake@cmake.org
Subject: [CMake] Best way to handle application data p
* Ruslan Baratov (ruslan_bara...@yahoo.com) wrote:
> > - I don't want to make an applications search for its data relative
> >to executable path
> >- There's no cross-platform way to get an executable path
> It's tricky but not impossible. Might be helpful:
> *
On 30/11/2015 02:10, Dmitry Marakasov wrote:
Hi!
This question bugs me for a long time so I though maybe someone has
a solution. I have a project which includes an application and some
data for it. An application needs to know path to its data files, so
I pass it via compiler definition:
On 30-Nov-15 09:10, Dmitry Marakasov wrote:
Hi!
This question bugs me for a long time so I though maybe someone has
a solution. I have a project which includes an application and some
data for it. An application needs to know path to its data files, so
I pass it via compiler definition:
Hi!
This question bugs me for a long time so I though maybe someone has
a solution. I have a project which includes an application and some
data for it. An application needs to know path to its data files, so
I pass it via compiler definition: ADD_DEFINITIONS(-DDATADIR="...")
The problem is that
So you want to hard code a location into the executable, but support
multiple locations without making multiple executables? These sound like
conflicting requirements.
Supporting multiple locations seems reasonable, so this suggests that
you'll have to change how your application looks for these
19 matches
Mail list logo
