Re: [darktable-dev] Testing darktable isolated from production

2019-05-03 Thread Andreas Schneider 
On Thursday, 2 May 2019 17:28:33 CEST dt-l...@stefan-klinger.de wrote:
> Florian Hühn (2019-May-02, excerpt):
> > If you rerun
> > cmake --build './build' --target install -- -j "$(nproc)"
> 
> ok.  But it is necessary to install, right?
> 
> > Just two thoughts about the isolation issue: Maybe consider setting
> > LD_LIBRARY_PATH as well to reduce your chances of accidentially mixing up
> > the *.so's with your productive version.
> 
> How would I set this up?  Is it just
> 
> export LD_LIBRARY_PATH="${prefix}/lib64"
> "${prefix}/bin/darktable" --configdir "${tmpCfg}" --cachedir
> "${tmpCache}"
> > (Personally I use a dedicated VM for
> > development, so take my suggestens as ideas, not as tested procedure.)
> 
> That would be overkill (meaning: I'm too lazy to go through all that
> hassle), I'd rather not do this at all.

Normally you can run applications out of the build dir from cmake, however 
darktable is a bit different because it loads a lot of modules using dlopen(). 
The path is normally the one of system installation dir.

It would be possible to support that, if you put the bin and modules in 
specific dirs, write the build dir to a config.h and then change the functions 
looking for the modules to first check the build dir and then the system dir. 
We could support this for e.g. debug builds.

I've worked on that some time ago but didn't have time to finish it.


___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Testing darktable isolated from production

2019-05-02 Thread jys 
On Thu, May 2, 2019, at 04:02, dt-l...@stefan-klinger.de wrote:

> Is there a way to achieve faster (re)compilation, and maybe running
> from the source tree without installing at all?

I take the additional precaution of using ~/.config/darktable26 as the data 
directory for the release version, and ~/.config/darktable-master for the git 
builds (which I install to /opt instead of /usr). This leaves the default 
~/.config/darktable directory a disposable "no man's land", with no harm done 
if one or the other build accidentally touches it, making it useful for testing 
with a "fresh" configuration just by deleting the contents.

-- 
jys
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Testing darktable isolated from production

2019-05-02 Thread dt-list 
Florian Hühn (2019-May-02, excerpt):
> If you rerun
> cmake --build './build' --target install -- -j "$(nproc)"

ok.  But it is necessary to install, right?

> Just two thoughts about the isolation issue: Maybe consider setting
> LD_LIBRARY_PATH as well to reduce your chances of accidentially mixing up
> the *.so's with your productive version.

How would I set this up?  Is it just

export LD_LIBRARY_PATH="${prefix}/lib64"
"${prefix}/bin/darktable" --configdir "${tmpCfg}" --cachedir "${tmpCache}"

> (Personally I use a dedicated VM for
> development, so take my suggestens as ideas, not as tested procedure.)

That would be overkill (meaning: I'm too lazy to go through all that
hassle), I'd rather not do this at all.


-- 
http://stefan-klinger.deo/X
I prefer receiving plain text messages, not exceeding 32kB. /\/
  \
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Testing darktable isolated from production

2019-05-02 Thread Šarūnas 
On 5/2/19 7:00 AM, dt-l...@stefan-klinger.de wrote:
> Hi,
> 
> for testing I'd like to run DT without installing it, and without
> interfering with my setup and foto collection.  Installing to an
> alternative destination would be ok, but I'd rather just recompile and
> run it.

Host's X11 and GPU (AMD and Nvidia) can be used from docker container. I
don't have pointers at the moment.

-- 
Šarūnas Burdulis
math.dartmouth.edu/~sarunas



signature.asc
Description: OpenPGP digital signature

Re: [darktable-dev] Testing darktable isolated from production

2019-05-02 Thread Florian Hühn 
If you rerun
cmake --build './build' --target install -- -j "$(nproc)"
only those files affected by your source code change will be recompiled. In
my experience that brings it down to a few seconds, even on a 2 core
machine.

Just two thoughts about the isolation issue: Maybe consider setting
LD_LIBRARY_PATH as well to reduce your chances of accidentially mixing up
the *.so's with your productive version. I don't know for sure how loading
of the *.cl kernels is handled but that might be another thing to
double-check. Just to be shure. (Personally I use a dedicated VM for
development, so take my suggestens as ideas, not as tested procedure.)

On Thu, May 2, 2019 at 1:03 PM  wrote:

> Hi,
>
> for testing I'd like to run DT without installing it, and without
> interfering with my setup and foto collection.  Installing to an
> alternative destination would be ok, but I'd rather just recompile and
> run it.
>
> What is needed to achieve this?  Currently I have
>
> tmp="/tmp";
>
> # copy some images
> tmpImages="${tmp}/dt-images";
> test -e "${tmpImages}" || rsync -av "${HOME}/foto/20190428-002"
> "${tmpImages}"
>
> # copy some config
> tmpCfg="${tmp}/dt-config"
> rsync -av --exclude='*.db' "${HOME}/.config/darktable/" "${tmpCfg}"
>
> # is this necessary?
> tmpCache="${tmp}/dt-cache"
> mkdir -p "${tmpCache}"
>
> # temporary install location
> prefix="${tmp}/dt-install"
>
> # building
> disable=(flickr libsecret kwallet unity tethering);
> ./build.sh -j "$(nproc)" \
>--prefix ${prefix} \
>"${disable[@]/#/--disable-}" \
>--buildtype Release
>
> # installing
> cmake --build './build' --target install -- -j "$(nproc)"
>
> # running
> "${prefix}/bin/darktable" --configdir "${tmpCfg}" --cachedir
> "${tmpCache}" \
>
> Is this enough to isolate DT from a "production" version and
> configuration?
>
> Is there a way to achieve faster (re)compilation, and maybe running
> from the source tree without installing at all?
>
> Thanks
> Stefan
>
>
> --
> http://stefan-klinger.deo/X
> I prefer receiving plain text messages, not exceeding 32kB. /\/
>   \
> ___
> darktable developer mailing list
> to unsubscribe send a mail to
> darktable-dev+unsubscr...@lists.darktable.org
>
>

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

[darktable-dev] Testing darktable isolated from production

2019-05-02 Thread dt-list 
Hi,

for testing I'd like to run DT without installing it, and without
interfering with my setup and foto collection.  Installing to an
alternative destination would be ok, but I'd rather just recompile and
run it.

What is needed to achieve this?  Currently I have

tmp="/tmp";

# copy some images
tmpImages="${tmp}/dt-images";
test -e "${tmpImages}" || rsync -av "${HOME}/foto/20190428-002" 
"${tmpImages}"

# copy some config
tmpCfg="${tmp}/dt-config"
rsync -av --exclude='*.db' "${HOME}/.config/darktable/" "${tmpCfg}"

# is this necessary?
tmpCache="${tmp}/dt-cache"
mkdir -p "${tmpCache}"

# temporary install location
prefix="${tmp}/dt-install"

# building
disable=(flickr libsecret kwallet unity tethering);
./build.sh -j "$(nproc)" \
   --prefix ${prefix} \
   "${disable[@]/#/--disable-}" \
   --buildtype Release

# installing
cmake --build './build' --target install -- -j "$(nproc)"

# running
"${prefix}/bin/darktable" --configdir "${tmpCfg}" --cachedir "${tmpCache}" \

Is this enough to isolate DT from a "production" version and
configuration?

Is there a way to achieve faster (re)compilation, and maybe running
from the source tree without installing at all?

Thanks
Stefan


--
http://stefan-klinger.deo/X
I prefer receiving plain text messages, not exceeding 32kB. /\/
  \
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org