Thank you, Karl. I will not have much time until next week, but I will be
back and try to propose a patch.
On Thu, Jun 3, 2021 at 11:00 PM madmurphy wrote:
> Thank you, Karl. I will not have much time until next week, but I will be
> back and try to propose a patch.
>
> Il giorno gio 3 giu 2021
No, my name is not Jim,
Sorry for being unclear. I wasn't guessing your name, but rather asking
Jim Meyering, long-time maintainer of Automake, to chime in.
make DIST_FLAGS='symlinks' dist
I can't think of any specific problem with the idea, except for the
general complication of adding
Thanks, Jacob. I've been trying to phrase that succinctly.
Git solved this problem for my development teams. Before git, we'd produce
downstream packages for each other if installables were needed. Mine is not
the only build process but for the same reasons I'm reluctant to build
packaging into th
madmurphy wrote:
But what if a developer wants to package something *for another developer*? It
is not unusual to have a non-bootstraped “dev” version of a package circulating
among developers
How is Git not adequate for this? If you need to pass files around,
there is the "git bundle" comm
Hi Karl, thank you for your message and the code review. I agree, and I
think I have got an idea. How about removing EXTRA_DIST_LINKS and adding a
Makefile variable named DIST_FLAGS *to be set on the fly*? So, for example,
imagine I have a package where my_link.txt is a symlink to the ChangeLog
fil
I was thinking that an idea could be to change my patch in order to
preserve symlinks only under --enable-maintainer-mode.
Seems ok to me, in principle. (Jim?)
The problem with making EXTRA_DIST_LINKS available in general is that,
invitably, packages will wrongly use it when creating tarb
*“What can EXTRA_DIST_LINKS achieve that AC_CONFIG_LINKS cannot?”*
With AC_CONFIG_LINKS() symlinks are present only in a configured package,
but a developer might want that symlinks are present before launching
configure, or even before launching the bootstrap script.
True about the development s
madmurphy wrote:
P.S. *“If I remember correctly, Autoconf also falls back to hardlinks or
copying the files if the system does not support symbolic links.”*: Same
goes for my patch. I use $(LN_S) for creating the links, and that falls
back to hardlinks when ln -s is not supported.
The differenc
P.S. *“If I remember correctly, Autoconf also falls back to hardlinks or
copying the files if the system does not support symbolic links.”*: Same
goes for my patch. I use $(LN_S) for creating the links, and that falls
back to hardlinks when ln -s is not supported.
--madmurphy
Hi Jacob,
Thank you for your reply. I am aware that symlinks and GNU coding standard
don't go well together, but I believe that there is a difference between
inviting to a standard and force to towards it. I am really convinced that
developers should be left free, and a written warning in a manual
madmurphy wrote:
I have created a patch for Automake to support a new Makefile variable
named EXTRA_DIST_LINKS. The purpose of the variable is that of creating
symlinks for the distributed archive.
The syntax is very simple: a space-separated list of tokens of the form
DEST:SOURCE – it is identi
I apologize, I had forgotten to write rm -rf "$${LNKPART}", for removing
possible existing links. Please find the new patch attached.
--madmurphy
Il giorno lun 31 mag 2021 alle ore 00:34 madmurphy
ha scritto:
> Hi there,
>
> I have created a patch for Automake to support a new Makefile variabl
Hi there,
I have created a patch for Automake to support a new Makefile variable
named EXTRA_DIST_LINKS. The purpose of the variable is that of creating
symlinks for the distributed archive.
The syntax is very simple: a space-separated list of tokens of the form
DEST:SOURCE – it is identical to t
13 matches
Mail list logo
