unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Phillip Lord <phillip.lord@russet.org.uk>
To: "Juan José García-Ripoll" <juanjose.garciaripoll@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Process to build standalone Emacs + deps in Windows
Date: Thu, 26 Mar 2020 22:28:41 +0000	[thread overview]
Message-ID: <87pncy21k6.fsf@russet.org.uk> (raw)
In-Reply-To: <867dz7tfk0.fsf@csic.es> ("Juan José García-Ripoll"'s message of "Thu, 26 Mar 2020 14:24:15 +0100")

Juan José García-Ripoll <juanjose.garciaripoll@gmail.com> writes:

> Phillip Lord <phillip.lord@russet.org.uk> 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



  parent reply	other threads:[~2020-03-26 22:28 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-22 13:03 Process to build standalone Emacs + deps in Windows Juan José García Ripoll
2020-03-22 13:59 ` Eli Zaretskii
2020-03-22 14:38   ` Juan José García-Ripoll
2020-03-22 17:25     ` Eli Zaretskii
2020-03-22 18:54     ` Phillip Lord
2020-03-22 19:35       ` Eli Zaretskii
2020-03-22 21:02         ` Phillip Lord
2020-03-23  3:23           ` Eli Zaretskii
2020-03-23 23:36             ` Phillip Lord
2020-03-24  3:27               ` Eli Zaretskii
2020-03-24 18:21                 ` Phillip Lord
2020-03-25 12:50       ` Juan José García-Ripoll
2020-03-25 14:43         ` Juan José García-Ripoll
2020-03-25 14:54           ` Juan José García-Ripoll
2020-03-25 15:33             ` Eli Zaretskii
2020-03-25 16:41               ` Juan José García-Ripoll
2020-03-25 17:03                 ` Eli Zaretskii
2020-03-25 17:22                   ` Juan José García-Ripoll
2020-03-25 17:34                     ` Eli Zaretskii
2020-03-25 22:40                     ` Phillip Lord
2020-03-26 13:16                       ` Juan José García-Ripoll
2020-03-26 14:32                         ` Eli Zaretskii
2020-03-26 22:20                         ` Phillip Lord
2020-03-25 22:34             ` Phillip Lord
2020-03-26  3:49               ` Stefan Monnier
2020-03-26 13:19                 ` Juan José García-Ripoll
2020-03-26 22:16                 ` Phillip Lord
2020-03-26 13:24               ` Juan José García-Ripoll
2020-03-26 14:37                 ` Eli Zaretskii
2020-03-28 16:01                   ` Juan José García-Ripoll
2020-03-28 16:23                     ` Eli Zaretskii
2020-03-28 19:36                     ` Phillip Lord
2020-03-28 19:41                       ` Eli Zaretskii
2020-03-26 22:28                 ` Phillip Lord [this message]
2020-03-25 15:25           ` Eli Zaretskii
2020-03-22 18:58     ` Phillip Lord
2020-03-22 18:32 ` phillip.lord

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87pncy21k6.fsf@russet.org.uk \
    --to=phillip.lord@russet.org.uk \
    --cc=emacs-devel@gnu.org \
    --cc=juanjose.garciaripoll@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).