Ticket #30 (new enhancement)

Opened 3 years ago

Last modified 3 years ago

Too heavy reliance on environment variables for building

Reported by: michelpons Owned by: marcus
Priority: major Milestone: 1.1 extension maintenance
Component: Build script Version: 2.1.2
Keywords: Cc:

Description

The Python script for building the TLB/PIA distribution relies heavily on environment variables to define the location of several applications/tools used during the process. In comparison, the build process for COBIA, while relying by default also on several environment variables, embeds logic to find the location of these applications should similar environment variables not be there. Since the logic has been developed for the COBIA build, it should be possible to use the very same logic for the build of the TLB/PIA distribution.

Change History

comment:1 Changed 3 years ago by michelpons

  • Component changed from Example Wix script to Build script

comment:2 Changed 3 years ago by jasper

Is there any specific component that cannot be located?

comment:3 Changed 3 years ago by michelpons

I have now defined all the necessary environment variables. The first one missing was SIGNTOOL for signtool.exe. On a machine which is aimed at building different distributions like COLTT, COBIA, TLB/PIA, requesting environment variables to be defined does not seem the best solution because of potential conflicts. Relying on logic to find the necessary tools may be not perfect but proved to work in the case of COBIA.

comment:4 Changed 3 years ago by jasper

I did that in Changeset 85, to make sure it works across computers. The setup prior to that, did not, for me.

If you want I can look up the mail about this subject.

If there are no other issues, I suggest to close this item as wontfix.

comment:5 Changed 3 years ago by jasper

Actually COBIA has it optional:

#find signtool
try:
    signtool=os.environ['SIGNTOOL']
except:
    signtool=None
if not signtool:
    #assume a Window Kit 10 is installed
    with winreg.OpenKey(winreg.HKEY_LOCAL_MACHINE,"SOFTWARE\\Microsoft\\Windows Kits\\Installed Roots") as key:
        path=winreg.QueryValueEx(key,"KitsRoot10")
    if not path:
        raise RuntimeError('Unable to locate a Windows 10 Platform SDK')
    signtool=os.path.join(path[0],'bin','x64','signtool.exe')
    if not os.path.isfile(signtool):
        signtool=os.path.join(path[0],'bin','x86','signtool.exe')
    if not os.path.isfile(signtool):
        for dir in glob.glob(os.path.join(path[0],'bin','10.*')):
            signtool=os.path.join(dir,'x64','signtool.exe')
            print(signtool)
            if os.path.isfile(signtool):
                break
            signtool=os.path.join(dir,'x86','signtool.exe')
            if os.path.isfile(signtool):
                break
    if not os.path.isfile(signtool):
        signtool=None
if (not signtool) or (not os.path.isfile(signtool)):
    raise RuntimeError('Unable to locate signtool.exe')
print('Found',signtool)

and IDL build does this:

# Function based on COBIA's build
def get_signtool_exe() -> str:

    signtool = os.getenv("signtool")  # try to get signtool from env variables

    if (not signtool) or (not os.path.isfile(signtool)):
        path = get_WinKits10_path()
        signtool = os.path.join(path[0], "bin", "x64", "signtool.exe")
        if not os.path.isfile(signtool):
            signtool = os.path.join(path[0], "bin", "x86", "signtool.exe")
        if not os.path.isfile(signtool):
            for dir in glob.glob(os.path.join(path[0], "bin", "10.*")):
                signtool = os.path.join(dir, "x64", "signtool.exe")
                if os.path.isfile(signtool):
                    break
                signtool = os.path.join(dir, "x86", "signtool.exe")
                if os.path.isfile(signtool):
                    break
        if not os.path.isfile(signtool):
            signtool = None
    if (not signtool) or (not os.path.isfile(signtool)):
        raise RuntimeError("Unable to locate signtool.exe")

    return signtool

So it used to take the same approach - but then it was detected that the .NET 3.5 / 2.0 tools needed to be used for the build, and get_WinKits10_path() was modified to look for the 7.0A SDK (I made a comment in the code about that) and that probably broke it.

Would not hurt to fix at some point, so don't close as wontfix after all.

comment:6 Changed 3 years ago by michelpons

I think this should be fixed in order to point to the proper tools. The way the contents of the environment variables is set up may not reflect what is exactly needed. Having a proper logic in place ensuring the right choice of tools seems a better approach to me.

comment:7 Changed 3 years ago by jasper

I was partly mistaken, get_WinKits10SDK_path was changed to locate 7A (I checked in the name change), but get_signtool_exe uses get_WinKits10_path (without the SDK) which works fine on my system.

I can only check why it does not work on your system if you share your desktop

Note: See TracTickets for help on using tickets.