From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6787079713742389248 Date: Thu, 23 Apr 2020 07:56:55 -0700 (PDT) From: vijai kumar To: isar-users Message-Id: <5a0aed27-fb1f-4d12-b35f-669d813582a5@googlegroups.com> In-Reply-To: References: <20200128193520.26504-1-Vijaikumar_Kanagarajan@mentor.com> <20200405164943.mccmlrje526qxyw3@yssyq.m.ilbers.de> Subject: Re: [PATCH] Introduce SCRIPTSDIR variable MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2155_1143199222.1587653815534" X-Google-Token: ELfZhvUFKAatein3SLA0 X-Google-IP: 192.94.34.34 X-TUID: ZkbevBSeRQ/e ------=_Part_2155_1143199222.1587653815534 Content-Type: multipart/alternative; boundary="----=_Part_2156_712916474.1587653815534" ------=_Part_2156_712916474.1587653815534 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On Monday, April 6, 2020 at 2:00:50 PM UTC+5:30, vijai kumar wrote: > > On Sun, Apr 5, 2020 at 10:19 PM Baurzhan Ismagulov > wrote: > > > > Hello Vijai Kumar, > > > > On Wed, Jan 29, 2020 at 01:05:20AM +0530, Vijai Kumar K wrote: > > > ISARROOT is mostly used with wic implemetation for the scripts > > > directory. Introduce SCRIPTSDIR to satisfy wic. > > > > > > When ISARROOT equivalent is needed, derive it from SCRIPTSDIR. > > > > Thanks for pursuing this annoying issue. I like the concept of having a > special > > variable for the directory. The advantage is that the code doesn't rely > on a > > specific directory structure. > > > > Now the patch fails to apply upon d90c2ab "wic-img: allow wic to find > bitbake > > binary", submitted shortly before yours. Looking at both together, I > realize > > that deriving the ISARROOT equivalent from SCRIPTSDIR makes it rely on > the > > directory structure again. > > Yes. Indeed. Please see comments below. > > > > > One possibilty would be to introduce both SCRIPTSDIR and the ISARROOT > > equivalent (calling it e.g. ISARDIR). What do you think? > > Hi Baurzhan, > > From the current ISAR next, there are atleast 4 different uses cases > for ISARROOT, > > 1. ISARROOT to find scripts directory for wic. > 2. ISARROOT to find bitbake/bin directory for wic. > 3. ISARROOT used as part of chown brought in by > f13b2bf71dd841eaebbbcd04f14a7fbcb2649572 to fix __pycache__ > permission. > 4. ISARROOT in ci-build.sh > > The first one could be addressed by a dedicated SCRIPTSDIR variable. > Second one could also be a dedicated variable? like BITBAKEDIR?? > Third one I am not sure if we could use any other location for stat. > Since in my build __pycache_ is created only in scripts/lib/wic/ > folder. In that case maybe we could stat LAYERDIR_core instead of > ISARROOT. > Fourth one can be replaced with a combination of getting > LAYERDIR_{core/isar} from bitbake -e and probably a new variable for > testsuite directory or any other way to get the gpg-keys path. > > I am just thinking if we should straight away adapt an ISARROOT > equivalent (ISARDIR) and have developers use those to to derive any > future > paths, or should we have dedicated variables to limit developers to > certain paths which are absolutely needed(SCRIPTSDIR, TESTSUITEDIR, > BITBAKEDIR etc). > I will send a V2 with this approach for review. It can be further discussed on top of that I guess. Thanks, Vijai Kumar K > I would opt the latter, as it would avoid unnecessary duplicate > definitions for the same path. For ex. path to meta can be > ${ISARROOT}/meta or could just be ${LAYERDIR_core}. Also this means > that we would establish the directory relationship at setup time, > easier to change or override in future without affecting large part of > the codebase. > Thanks, > Vijai Kumar K > > > > > > With kind regards, > > Baurzhan. > > > > -- > > You received this message because you are subscribed to the Google > Groups "isar-users" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to isar-users+unsubscribe@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/isar-users/20200405164943.mccmlrje526qxyw3%40yssyq.m.ilbers.de. > > ------=_Part_2156_712916474.1587653815534 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Monday, April 6, 2020 at 2:00:50 PM UTC+5:30, v= ijai kumar wrote:
On Sun, Apr 5= , 2020 at 10:19 PM Baurzhan Ismagulov <ibr@radix50.net> wrote:
>
> Hello Vijai Kumar,
>
> On Wed, Jan 29, 2020 at 01:05:20AM +0530, Vijai Kumar K wrote:
> > ISARROOT is mostly used with wic implemetation for the script= s
> > directory. Introduce SCRIPTSDIR to satisfy wic.
> >
> > When ISARROOT equivalent is needed, derive it from SCRIPTSDIR= .
>
> Thanks for pursuing this annoying issue. I like the concept of hav= ing a special
> variable for the directory. The advantage is that the code doesn&#= 39;t rely on a
> specific directory structure.
>
> Now the patch fails to apply upon d90c2ab "wic-img: allow wic= to find bitbake
> binary", submitted shortly before yours. Looking at both toge= ther, I realize
> that deriving the ISARROOT equivalent from SCRIPTSDIR makes it rel= y on the
> directory structure again.

Yes. Indeed. Please see comments below.

>
> One possibilty would be to introduce both SCRIPTSDIR and the ISARR= OOT
> equivalent (calling it e.g. ISARDIR). What do you think?

Hi Baurzhan,

From the current ISAR next, there are atleast 4 different uses cases
for ISARROOT,

1. ISARROOT to find scripts directory for wic.
2. ISARROOT to find bitbake/bin directory for wic.
3. ISARROOT used as part of chown brought in by
f13b2bf71dd841eaebbbcd04f14a7fbcb2649572 to fix __pycache__
permission.
4. ISARROOT in ci-build.sh

The first one could be addressed by a dedicated SCRIPTSDIR variable.
Second one could also be a dedicated variable? like BITBAKEDIR??
Third one I am not sure if we could use any other location for stat.
Since in my build __pycache_ is created only in scripts/lib/wic/
folder. In that case maybe we could stat LAYERDIR_core instead of
ISARROOT.
Fourth one can be replaced with a combination of getting
LAYERDIR_{core/isar} from bitbake -e and probably a new variable for
testsuite directory or any other way to get the gpg-keys path.

I am just thinking if we should straight away adapt an ISARROOT
equivalent (ISARDIR) and have developers use those to to derive any
future
paths, or should we have dedicated variables to limit developers to
certain paths which are absolutely needed(SCRIPTSDIR, TESTSUITEDIR,
BITBAKEDIR etc).

I will send a V2 with this approach fo= r review. It can be further
discussed on top of that I guess.
=C2=A0
Thanks,
Vijai Kumar K


I would opt the latter, as it would avoid unnecessary duplicate
definitions for the same path. For ex. path to meta can be
${ISARROOT}/meta or could just be ${LAYERDIR_core}. Also this means
that we would establish the directory relationship at setup time,
easier to change or override in future without affecting large part of
the codebase.=C2=A0

Thanks,
Vijai Kumar K


>
> With kind regards,
> Baurzhan.
>
> --
> You received this message because you are subscribed to the Google= Groups "isar-users" group.
> To unsubscribe from this group and stop receiving emails from it, = send an email to isar-users+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/= isar-users/20200405164943.mccmlrje526qxyw3%40yssyq.m.ilbers.= de.
------=_Part_2156_712916474.1587653815534-- ------=_Part_2155_1143199222.1587653815534--