emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Process to build standalone Emacs + deps in Windows


From: Phillip Lord
Subject: Re: Process to build standalone Emacs + deps in Windows
Date: Thu, 26 Mar 2020 22:28:41 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.90 (gnu/linux)

Juan José García-Ripoll <address@hidden> writes:

> Phillip Lord <address@hidden> writes:
>> In reply to two of your emails, sorry:
>>
>> +    if dependencies:
>> +        print(f"Package {pkg} depends on:")
>> +        for d in dependencies:
>> +            print(f" -> {d}")
>> +
>>
>> I wouldn't add this. It's only useful some of the time, not in normal
>> usage, and anyway "pactree" does the same thing better.
>
> Right now the scripts do not provide this information but do emit a line
> "Adding *package name*" I personally find it more informative to at
> least instruct why the package is added. If pactree is more useful, it
> is not used anywhere in the current code.

pactree gives a graphical picture of all the dependencies. It's not used
in the current code, since I refactored it to drop a lot of
dependencies. But, as a tool it will still tell you what depends on what.


>> +    ## exclude files
>> +    excludes=['lib/*.a', # No files to link against
>> +              'lib/*/*.exe', # No hidden executables
>> +              'libexec/*/*.exe',
>>  [...]
>>
>> This list would need to go near the front, so we have a clean
>> configuration section. It also displays the key problem -- it's really
>> long and non obvious so a maintenance burden
>
> Not really. The *.exe can be deduced from the pacman files.


Not sure I understand here to be honest.


>> If we just did a few big top level directories, would that not solve all
>> the problems.
>
> I proposed to remove complete directories but it seems it is not an option.
>
>> +# The dependency extraction relies on an English version of pacman
>> +# We need to configure the locale to match the expectations
>> +if 'LANG' in os.environ:
>> +    os_lang = os.environ['LANG']
>> +    if (len(os_lang) > 2) and (os_lang[0:2] != 'en'):
>> +        os.environ['LANG']='en_US'
>> I am vaguely curious what it looks like in Spanish. I thought the output
>> was fairly mechanistic.
>
> Your filter relies on the English word "depends on"
>     ## Extract the "Depends On" line
>     depends_on = [x for x in package_info if x.startswith("Depends On")][0]
> This is heavily locale-dependent

Oh yeah, that's funny.



>> - Since we are pulling in compression utilities, we may just as well tell the
>>   configuration to compress the *.el files. Windows is the only platform 
>> where
>>   this does not happen
>>
>> No, because I generate the no-deps version first, then add the deps. The
>> -no-deps version doesn't have the compression utilities. Of course, we
>> do not need the *.el files at all.
>
> The no-deps version does not have the compression utilities but it is
> not intended to be used by itself, as it depends on all the *.dll Hence,
> one may argue that it can be built to support compression.


The no-deps version should work fine all by itself. Indeed, this used to
be the only form of Emacs distribution for windows. It just won't do
some things.


>
>>   b) I realized that Cairo is pulled in as a dependency, but Emacs is
>>   built without support for Cairo. Is this intentional?
>>
>> No, it will be a transitive dependency of something. pactree will
>> reveal!
>
> My simple lines instructing what depends on what showed this: it is
> pulled in by rsvg. There were some earlier emails about this.


Yes, I know.

Phil



reply via email to

[Prev in Thread] Current Thread [Next in Thread]