On 12/17/2014 08:15 PM, Dmitri Pal wrote:
> On 12/17/2014 01:06 PM, Nikolai Kondrashov wrote:
>> On 12/17/2014 07:37 PM, Lukas Slebodnik wrote:
>>> On (17/12/14 19:11), Nikolai Kondrashov wrote:
>>>> On 12/17/2014 06:44 PM, Lukas Slebodnik wrote:
>>>>> You can use different prefix even with make check.
>>>>
>>>> Sure, but then it won't be just any "make check" anymore.
It will
>>>> require a
>>>> special "configure" invocation to work.
>>>>
>>>>> "make distcheck" uses it in such way. It doesn't make
sense to
>>>>> reinvent wheel.
>>>>> The only difference is that make distcheck does not run program.
>>>>> It just calls
>>>>> "make install" and "make uninstall" (very
simplified version)
>>>>>
>>>>> Here is simplified part of distcheck. We can use similar approach.
>>>>>
>>>>> distcheck: dist
>>>>> GZIP=$(GZIP_ENV) gzip -dc $(distdir).tar.gz | $(am__untar)
>>>>> ;;\
>>>>> chmod -R a-w $(distdir)
>>>>> chmod u+w $(distdir)
>>>>> mkdir $(distdir)/_build $(distdir)/_inst
>>>>> chmod a-w $(distdir)
>>>>> test -d $(distdir)/_build || exit 0; \
>>>>> dc_install_base=`$(am__cd) $(distdir)/_inst && pwd | sed
-e
>>>>> 's,^[^:\\/]:[\\/],/,'` \
>>>>> && dc_destdir="$${TMPDIR-/tmp}/am-dc-$$$$/"
\
>>>>> && am__cwd=`pwd` \
>>>>> && $(am__cd) $(distdir)/_build \
>>>>> && ../configure \
>>>>> $(AM_DISTCHECK_CONFIGURE_FLAGS) \
>>>>> $(DISTCHECK_CONFIGURE_FLAGS) \
>>>>> --srcdir=.. --prefix="$$dc_install_base" \
>>>>> ^^^^^^^^^^^^^^^^^
>>>>> custom prefix in make distcheck
>>>>> && $(MAKE) $(AM_MAKEFLAGS) \
>>>>
>>>> Yes, it invokes "configure" and does a separate build.
>>>>
>>>> I'm not sure what you're suggesting and I wouldn't like to
guess.
>>>> Could you please clarify?
>>>>
>>> It would be better to start from beginnig. You just mentioned some
>>> problems.
>>> and I just wanted to give a hint not a full plan.
>>>
>>> You haven't mentioned your desing(proposal/plan). IMO, there are
>>> more ways how
>>> to run cwrap tests. I can see what's your problem but I cannot
>>> image you plan.
>>>
>>> Could you describe (aproximatelly in ten points) what was your plan?
>>> Then I will try fit idea from previous mail to your design.
>>
>> I'm not sure I'll be able to find 10 points, but here's what I'm
>> trying to do.
>>
>> I'd like to run nss/sssd/LDAP integration tests as part of a regular
>> "make
>> check". I.e. not imposing any more restrictions/conditions on the
>> "make check"
>> than we have now. Including running under any developer's user
>> account, not
>> counting on a specific build tree location or other
>> files/directories being
>> present additionally outside the build directory, and not requiring any
>> special arguments to "make". I.e. just keep the current "make
check"
>> requirements as they are.
>>
>> To make that work we need the LDAP server to work with arbitrary
>> configuration
>> and data locations (in our case under the build tree). OpenLDAP can
>> do that,
>> with locations specified at startup time. Not sure about 389-ds.
>>
>> We also need all sssd components involved in the tests (at least
>> libnss_sss
>> and sssd) to be able to work with arbitrary configuration, data and
>> socket
>> locations (under the build tree, again). At the moment we can change
>> these
>> only at the build time, via "configure" invocation.
>>
>> We can probably make the "check" target depend on an additional
>> build with
>> changed prefix, but it feels too much of a hassle and a slowdown for
>> the RPM
>> build. Making "contrib/ci/run" do the special-prefix build instead
>> seems
>> easier and simpler.
>>
>> Nick
>> _______________________________________________
>> sssd-devel mailing list
>> sssd-devel(a)lists.fedorahosted.org
>>
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>
> If we do something in the area we should consider the config DB and
> config file refactoring we have on our plate anyways.
> IMO it would make sense to pass a path to sssd.conf, directory where
> configuration snippets would be expected and where the cache DBs are
> located to SSSD as startup parameters.
> So if they are passed they would overwrite the ones defined in the code.
> That would help with some changes we plan to do and also with the CI.
>
> Would that be an option?
This would help, but the libraries such as libnss_sss would need to be
supplied the changed paths in some other way, it seems.
Nick
Environment variables?
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.