> Evolution depends on the evolution-data-server, not only as a usual
> library dependency, but also because things are just split into the two
> projects and to fix a problem in Evolution can mean to touch the
> evolution-data-server code, sometimes only there, sometimes on both places.
Thanks
Hi,
On Mon, 2020-11-23 at 21:00 +0100, Markus Elfring via evolution-hackers
wrote:
> This build parameter can trigger also further development challenges.
No, as long as you use it properly.
Evolution depends on the evolution-data-server, not only as a usual
library dependency, but also
> … Instead, use DESTDIR properly
I find that this happening here.
> (aka not at all,
I am using such an environment variable for intended purposes,
> because you are not a packager,
Such a view can be appropriate at the moment.
> and configure the project properly,
Such an expectation
On Mon, 2020-11-23 at 17:15 +0100, Markus Elfring via evolution-hackers
wrote:
> How do you think about to take further software extension
> possibilities into account here?
Hi,
no, I'm sorry. Instead, use DESTDIR properly (aka not at all, because
you are not a packager, you are not
> In file included from
> /home/elfring/Projekte/Gnome/Evolution/lokal/src/e-util/e-util.h:266,
> from
> /home/elfring/Projekte/Gnome/Evolution/lokal/src/e-util/test-proxy-preferences.c:18:
> /home/elfring/Projekte/Gnome/Evolution/lokal/src/e-util/e-webdav-browser.h:26:10:
>
> When you tell the software that the files will be located in /a/b (in
> this case by using -DCMAKE_INSTALL_PREFIX=/a/b) and then you install it
> into /g/h (by using DESTDIR=/g/h make install) then it does exactly
> what you told it.
This part should usually be fine.
> b) you do not need to
On Mon, 2020-11-16 at 15:45 +0100, Markus Elfring via evolution-hackers
wrote:
> It seems that this is not directly supported so far with the provided
> version.
Hi,
no, no, no, I do not think so.
When you tell the software that the files will be located in /a/b (in
this case by using
> I did not notice any limitation.
A build system configuration limitation was demonstrated by missing
a known header file which is available in another selected storage location.
>> I would like to reuse software components directly from a “staged”
>> (test) installation.
>
> Sure, then do
On Mon, 2020-11-16 at 14:52 +0100, Markus Elfring via evolution-hackers
wrote:
> I noticed specific limitations.
Hi,
I did not notice any limitation.
> I would like to reuse software components directly from a “staged”
> (test) installation.
Sure, then do configure it as such.
> https://www.gnu.org/prep/standards/html_node/DESTDIR.html
I have read the document section “7.2.4 DESTDIR: Support for Staged Installs”
once more.
> Hint: You misuse the DESTDIR variable.
I got obviously an other impression.
> Hence, there's nothing to be changed in the build process.
I
On Fri, 2020-11-13 at 22:03 +0100, Markus Elfring via evolution-hackers
wrote:
> > Make sure you provide precise commands to reproduce the problem.
>
> The provided build data show helpful information for the failure
> to include a special header file.
Hi,
pity you denied to do the
> could you use bug tracker to fill bugs, please?
I hope that the clarification will be continued with the bug report
“Make selection of installation contexts configurable for software build
components”.
https://gitlab.gnome.org/GNOME/evolution/-/issues/1226
Regards,
Markus
On Fri, 2020-11-13 at 22:32 +0100, Markus Elfring via evolution-hackers
wrote:
> > and also always provided actual problem descriptions and use cases
> > in
> > your GitLab tickets (as requested many times before).
>
> Do you find my experience report acceptable and reasonable for the
> desired
>
> and also always provided actual problem descriptions and use cases in
> your GitLab tickets (as requested many times before).
Do you find my experience report acceptable and reasonable for the desired
clarification of a compilation failure?
Regards,
Markus
On Fri, 2020-11-13 at 22:23 +0100, Markus Elfring via evolution-hackers
wrote:
> > Not if you finally decided to follow the scheme and guidelines in
> > https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
> > (as requested many times before).
>
> Would you get into the mood to
> Not if you finally decided to follow the scheme and guidelines in
> https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
> (as requested many times before).
Would you get into the mood to achieve further improvements for the affected
software build system (eventually also
On Fri, 2020-11-13 at 22:03 +0100, Markus Elfring via evolution-hackers
wrote:
>
> There can be a risk that the communication will evolve in ways
> so that such an issue would be locked again before a desirable result
> would be achieved.
Not if you finally decided to follow the scheme and
> could you use bug tracker to fill bugs, please?
I can register another clarification request also in an issue tracker.
> Apart of it being much easier to track the issues,
There can be a risk that the communication will evolve in ways
so that such an issue would be locked again before a
18 matches
Mail list logo
