Re: fvwm3 repo (WAS: Re: Separate or common project infrastructure fvwm v2/v3.)

[Ethan Raynor]

Hi,

Is it OK to request these sorts of conversations take place someplace
else? I did not know before that there's a lot of heated
conversations. I don't want to have to read these.

Please be considerate. Or agree on something and move on, may be?

Ethan


On Sun, Nov 13, 2016 at 1:43 AM, Dominik Vogt  wrote:
> On Sun, Nov 13, 2016 at 01:05:23AM +, Thomas Adam wrote:
>> On Thu, Oct 27, 2016 at 01:23:23AM +0100, Thomas Adam wrote:
>> > "Copying" was a bad choice of words.  With fvwm3, what I would suggest is
>> > taking the current fvwm2 repository (including all of its branches) and
>> > making that the basis for fvwm3.  That way, we can change it however we 
>> > like.
>> > We're then able to link fvwm2's repo in to easily backport changes using
>> > standard git commands, etc.  It's something I'd be happy to run through if
>> > that's required, or wanted.
>>
>> Controversially, I've gone ahead and created a fvwm3 repository [1].  It has
>> been set up as fvwm2 was; the only difference is there's no tags.  The master
>> branch is the same from fvwm2.
>>
>> I've aleady gone ahead and made fvwm3 rename key parts.  So for example, the
>> binary is currently called 'fvwm3' and the share prefix installs to
>> $PREFIX/share/fvwm3.
>
> Why on earth do we have to repeat the mistake of the past by
> putting the version number in the project name *again*?  Every
> other project manages backwards incompatible releases just fine,
> only fvwm changes its name with each major release.  This just
> complicates things, and helps nobody.  That's what configure's
> binary suffix is for.
>
>> I'm not necessarily expecting this to remain as-is for
>> too long, but it does mean that fvwm3 can be installed along side fvwm2.
>
>
>> 1.  How do I port fixes from fvwm3 -> fvwm2?
>>
>> You can do this with remotes.  From fvwm3's POV:
>>
>>   git remote add fvwm2 g...@github.com:fvwmorg/fvwm.git
>>   git fetch -n fvwm2
>>   git checkout -t origin/fvwm2 fvwm2-master
>>   git cherry-pick COMMIT1 COMMIT2
>>   git push
>>
>> This will also handle file rename cases.  So for example, fvwm/fvwm3.c would
>> map to fvwm/fvwm.c in fvwm2's repository, as git understands file renames.
>
> In the past couple of years I haven't been contributing that much,
> and I'm absolutely for having the sources in git.  But over the
> recent years, I've tested the initiol fvwm git repo, then switched
> to the mvwm repo, rewritten all the config files on various
> machines to switch to mvwm, in the mean time backported fixes from
> mvwm to fvwm (with some amount of merge conflicts), converted all
> the icons to a different format because mvwm required that,
> switched back to the fvwm repo, backported the parser branch to
> the fvwm repo (very annoying), rewritten the config from mvwm to
> fvwm yet again.  And I've got to rewrite it *again*, manage two
> different configs and fiddle with two repos in parallel, just to
> be able to install two versions in parallel, which is already
> possible (and if not, this needs to be fixed anyway).
>
> By the way, everybody else would call their versions fvwm-2 and
> fvwm-3, and that's what I'll do, starting now.
>
> Ciao
>
> Dominik ^_^  ^_^
>
> --
>
> Dominik Vogt
>

Re: fvwm3 repo (WAS: Re: Separate or common project infrastructure fvwm v2/v3.)

[Dominik Vogt]

On Sun, Nov 13, 2016 at 05:13:22PM +, Thomas Adam wrote:
> On Sun, Nov 13, 2016 at 04:09:14PM +0100, Dominik Vogt wrote:
> > Bofore you start working on that, please take a look at the
> > dv/fix-transform-name branch.
> 
> OK, this looks good.  I'm surprised that FvwmCommand.sh is installed to
> /.../libexec/fvwm/$(VERSION) without execute permissions.   But this isn't a
> bug, it seems to always have been the case.

It's still not good.  Isn't there a standard Automake way to
install shell scripts?

> I suppose the next step is to remove the compatability symlinks, both in terms
> for fvwm2 -> fvwm and xpmroot, and the symlinks for the documentation.  You
> can do that on top of what you have, if you like.

I think it's more important to first fix the Makefile.am in
default-config and its subdirs as written in the other thread.
Furthermore, the symlinks are not properly installed when
--program-transform-name is used, and they are not properly
uninstalled.  (I certainly can do this, but I'd like to give the
author of the Makefile.am the chance to fix it - I know it's
tedious, but it's neccessary.)

By the way, any idea why "make distcheck" has never caught the
faulty uninstallation of the symlinks?

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: fvwm3 repo (WAS: Re: Separate or common project infrastructure fvwm v2/v3.)

[Thomas Adam]

On Mon, Nov 14, 2016 at 01:52:51AM +0100, Dominik Vogt wrote:
> It's still not good.  Isn't there a standard Automake way to
> install shell scripts?

IIRC, there's bin_SCRIPTS -- ah, poking around reveals this:

https://www.gnu.org/software/automake/manual/html_node/Scripts.html

Although we're already using that in places across fvwm.

> uninstalled.  (I certainly can do this, but I'd like to give the
> author of the Makefile.am the chance to fix it - I know it's
> tedious, but it's neccessary.)

Heh.  Very well.  I will take a look.

> By the way, any idea why "make distcheck" has never caught the
> faulty uninstallation of the symlinks?

Nope, no idea.

I find dist/distcheck to be some seriously weird automake black magic which
I've never fully understood.

-- Thomas Adam

Re: fvwm3 repo (WAS: Re: Separate or common project infrastructure fvwm v2/v3.)

[Dominik Vogt]

Please don't top post on the fvwm lists.

On Mon, Nov 14, 2016 at 12:44:47AM +, Ethan Raynor wrote:
> it's those points i would like to see put elsewhere

I've completely understood that it bothers you.  If you don't want
to read it, don't.  This is an unavoidable part of public software
development.

> as that doesnt have much - if anything- to do with fvwm.

Discussing the fvwm infrastructure and the personal opinions about
it is completely on topic.  This list is not a place where
politeness or political correctness is exspecially important.

> or am i wrong?

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: fvwm3 repo (WAS: Re: Separate or common project infrastructure fvwm v2/v3.)

[Ethan Raynor]

Hi,

I can understand personal opinions - they're important and they happen
all the time with projects, I understand that. But I don't think it is
very fair to say I should not read it - when I won't know weather it's
there or not to start with. So I think just not having those
conversations is better.

Thanks again though.

Ethan

On Mon, Nov 14, 2016 at 1:03 AM, Dominik Vogt  wrote:
> Please don't top post on the fvwm lists.
>
> On Mon, Nov 14, 2016 at 12:44:47AM +, Ethan Raynor wrote:
>> it's those points i would like to see put elsewhere
>
> I've completely understood that it bothers you.  If you don't want
> to read it, don't.  This is an unavoidable part of public software
> development.
>
>> as that doesnt have much - if anything- to do with fvwm.
>
> Discussing the fvwm infrastructure and the personal opinions about
> it is completely on topic.  This list is not a place where
> politeness or political correctness is exspecially important.
>
>> or am i wrong?
>
> Ciao
>
> Dominik ^_^  ^_^
>
> --
>
> Dominik Vogt
>

Re: fvwm3 repo (WAS: Re: Separate or common project infrastructure fvwm v2/v3.)

[Dominik Vogt]

On Mon, Nov 14, 2016 at 12:58:42AM +, Thomas Adam wrote:
> On Mon, Nov 14, 2016 at 01:52:51AM +0100, Dominik Vogt wrote:
> > By the way, any idea why "make distcheck" has never caught the
> > faulty uninstallation of the symlinks?
> 
> Nope, no idea.
> 
> I find dist/distcheck to be some seriously weird automake black magic which
> I've never fully understood.

As far as I understand it:

1. Make everything.
2. Build a tarball from the build result, using the files
   mentioned in the Makefile.am.
3. Create three subdirs (SOURCE, BUILD, INSTALL or whatever the
   exact names are).
4. Extract the tarball into SOURCE.
5. Unprotect BUILD, write protect SOURCE and protect INSTALL from
   any access.
6. cd into the builddir, build everything with --srcdir=SOURCE and
   --prefix=INSTALL.
   => This makes sure that all files built are placed in BUILD,
  all source files are taken from SOURCE, and nothing is
  installed or built in INSTALL during the build step.
7. Protect SOURCE from any access, write protect BUILD and
   unprotect INSTALL.
8. make install
   => This makes sure that installing actually places the files
  in INSTALL and not elsewhere.
9. make uninstall and check that nothing is left in INSTALL
   except empty directories.
   => Check that everything put into INSTALL ist removed, and that
  files are actually removed from the INSTALL and not from
   SOURCE or BUILD.

If "make distcheck" fails, it's normally either because some file
is missing from the tarball or not properly uninstalled.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: fvwm3 repo (WAS: Re: Separate or common project infrastructure fvwm v2/v3.)

[Dominik Vogt]

On Mon, Nov 14, 2016 at 12:07:42AM +, Ethan Raynor wrote:
> Is it OK to request these sorts of conversations take place someplace
> else?

No.

If there's one place for discussing fvwm development, it's this
mailing list.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: fvwm3 repo (WAS: Re: Separate or common project infrastructure fvwm v2/v3.)

[Dominik Vogt]

On Mon, Nov 14, 2016 at 01:11:57AM +, Ethan Raynor wrote:
> I can understand personal opinions - they're important and they happen
> all the time with projects, I understand that. But I don't think it is
> very fair to say I should not read it - when I won't know weather it's
> there or not to start with. So I think just not having those
> conversations is better.

I don't.  Software development is difficult enough without
worrying about the feelings of the readers.  This just eats up
time that could be used to do some useful work.

--

Please don't top post on this list, i.e. put your answers below
the text you're refering to, not above it.
https://en.wikipedia.org/wiki/Posting_style

BAD
 ^
 |
 |
> On Mon, Nov 14, 2016 at 1:03 AM, Dominik Vogt  wrote:
> > Please don't top post on the fvwm lists.
> >
> > On Mon, Nov 14, 2016 at 12:44:47AM +, Ethan Raynor wrote:
> >> it's those points i would like to see put elsewhere
 |
 |
 v
GOOD

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: fvwm3 repo (WAS: Re: Separate or common project infrastructure fvwm v2/v3.)

[Dominik Vogt]

On Sun, Nov 13, 2016 at 02:06:19AM +, Thomas Adam wrote:
> On Sun, Nov 13, 2016 at 02:43:13AM +0100, Dominik Vogt wrote:
> > Why on earth do we have to repeat the mistake of the past by
> > putting the version number in the project name *again*?  Every
> > other project manages backwards incompatible releases just fine,
> > only fvwm changes its name with each major release.  This just
> > complicates things, and helps nobody.  That's what configure's
> > binary suffix is for.
> 
> So what would you rather, and to what extent should this happen?

See attached patch.  The Makefile.am need some tuning because some
names are hard coded in install...local rules (FvwmCommand.sh,
FvwmCommand.pm, xpmroot*, fvwm2*, message catalogs).  It's easy to
firgure out; just configure with --prefix=some-private-dir, ass
program-suffix and program-prefix, then install and see which
files end up in the wrong place.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
>From 08f22e1a9aa492cf084020ea9d3c7dbf286659ea Mon Sep 17 00:00:00 2001
From: Dominik Vogt 
Date: Sun, 13 Nov 2016 04:16:14 +0100
Subject: [PATCH] !

---
 configure.ac |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index e3a5424..665e77b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -93,9 +93,11 @@ AC_MSG_RESULT([assuming $PERL as perl location])
 AC_SUBST(PERL)
 
 # installation paths
-FVWM_MODULESUBDIR=/${PACKAGE}/${VERSION}
-FVWM_DATASUBDIR=/${PACKAGE}
-FVWM_DOCSUBDIR=/doc/${PACKAGE}
+transform=`echo "${program_transform_name}" | "$SED" -e 's/\\$\\$/\\$/'`
+PPACKAGE=`echo "${PACKAGE}" | "$SED" -e "${transform}"`
+FVWM_MODULESUBDIR=/${PPACKAGE}/${VERSION}
+FVWM_DATASUBDIR=/${PPACKAGE}
+FVWM_DOCSUBDIR=/doc/${PPACKAGE}
 
 AC_ARG_ENABLE(package-subdirs,
   AS_HELP_STRING([--disable-package-subdirs],
-- 
1.7.10.4

Re: fvwm3 repo (WAS: Re: Separate or common project infrastructure fvwm v2/v3.)

[Dominik Vogt]

On Sun, Nov 13, 2016 at 02:03:52PM +, Thomas Adam wrote:
> On Sun, Nov 13, 2016 at 04:30:23AM +0100, Dominik Vogt wrote:
> > On Sun, Nov 13, 2016 at 02:06:19AM +, Thomas Adam wrote:
> > > On Sun, Nov 13, 2016 at 02:43:13AM +0100, Dominik Vogt wrote:
> > > > Why on earth do we have to repeat the mistake of the past by
> > > > putting the version number in the project name *again*?  Every
> > > > other project manages backwards incompatible releases just fine,
> > > > only fvwm changes its name with each major release.  This just
> > > > complicates things, and helps nobody.  That's what configure's
> > > > binary suffix is for.
> > > 
> > > So what would you rather, and to what extent should this happen?
> > 
> > See attached patch.  The Makefile.am need some tuning because some
> > names are hard coded in install...local rules (FvwmCommand.sh,
> > FvwmCommand.pm, xpmroot*, fvwm2*, message catalogs).  It's easy to
> > firgure out; just configure with --prefix=some-private-dir, ass
> > program-suffix and program-prefix, then install and see which
> > files end up in the wrong place.
> 
> Right.  I'd forgotten that automake allowed for --program-{prefix,suffix} --
> that makes things much easier.  So I'll rejig some things and use this.
> 
> I can see there's a few things which will need adjusting.  We won't need the
> fvwm2 symlink at all since that would be misleading, surely?  The other parts
> you've identified shouldn't be too difficult to fix.  I'm unsure what should
> happen with the gettext files, and if they need namespacing at all.  I don't
> make use of such things.

Bofore you start working on that, please take a look at the 
dv/fix-transform-name branch.

> One observation I've got is:
> 
> > +transform=`echo "${program_transform_name}" | "$SED" -e 's/\\$\\$/\\$/'`
> > +PPACKAGE=`echo "${PACKAGE}" | "$SED" -e "${transform}"`
> 
> Is this not what the option '--program-transform-name=program' is doing?  See:

Roughly, but it only modifies program names while we also want to
change some subdir names.  And it does not work in Makefile.am
hooks.  :-/

> https://www.gnu.org/software/automake/manual/html_node/Renaming.html

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Request for testing help

[Dominik Vogt]

Hi folks,

I'm still struggling with reproducing a creash in the a crash in
the branch dv/new-parser-2.  It has something to do with passing
around arguments from one complex function to another (possibly
nested deeper).  In some situations, the memory for an argument is
freed while still being in use somewhere else.  It may also have
something to do with multiple things happening at once, like
switching pages or so (triggered by a module?).

The biggest debugging problem is that it happens very rarely with
my config, maybe twice a year.  If any of you had the time and
leisure to fiddle around a bit with nested complex functions with
lots of arguments and identified a reproduceable case that
crashes, that would help me a lot to finally identify and fix the
problem.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: [fvwmorg/fvwm] f508f5: Fix installation and uninstallation with --program...

[Dominik Vogt]

On Sun, Nov 13, 2016 at 07:00:29AM -0800, Dominik Vogt wrote:
>   Branch: refs/heads/dv/fix-program-transform
>   Home:   https://github.com/fvwmorg/fvwm
>   Commit: f508f5f574de461e21fa5ad2d4d2d50eb75378df
>   
> https://github.com/fvwmorg/fvwm/commit/f508f5f574de461e21fa5ad2d4d2d50eb75378df
>   Author: Dominik Vogt 
>   Date:   2016-11-13 (Sun, 13 Nov 2016)
> 
>   Changed paths:
> M bin/Makefile.am
> M configure.ac
> M doc/fvwm/Makefile.am
> M fvwm/Makefile.am
> M modules/FvwmAnimate/Makefile.am
> M modules/FvwmAuto/Makefile.am
> M modules/FvwmBacker/Makefile.am
> M modules/FvwmBanner/Makefile.am
> M modules/FvwmButtons/Makefile.am
> R modules/FvwmCommand/FvwmCommandS.c
> M modules/FvwmCommand/Makefile.am
> A modules/FvwmCommandS/FvwmCommand.h
> A modules/FvwmCommandS/FvwmCommandS.c
> A modules/FvwmCommandS/Makefile.am
> A modules/FvwmCommandS/fifos.c
> M modules/FvwmConsole/Makefile.am
> M modules/FvwmCpp/Makefile.am
> M modules/FvwmEvent/Makefile.am
> M modules/FvwmForm/Makefile.am
> M modules/FvwmIconMan/Makefile.am
> M modules/FvwmIdent/Makefile.am
> M modules/FvwmM4/Makefile.am
> M modules/FvwmPager/Makefile.am
> M modules/FvwmPerl/Makefile.am
> M modules/FvwmProxy/Makefile.am
> M modules/FvwmRearrange/Makefile.am
> M modules/FvwmScript/Makefile.am
> M modules/Makefile.am
> 
>   Log Message:
>   ---
>   Fix installation and uninstallation with --program-transform-name.
> 
> Had to move FvwmCommandS to a different subdir to do this.

Actually, I find commit messages without the diffs really useless.
Could we activate the diffs with some size limit?

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

default-config installation

[Dominik Vogt]

This is not how to install files with automake:

default-config/Makefile.am:

> ## Process this file with automake to create Makefile.in
> 
> configdir = @FVWM_DATADIR@/default-config
> inst_location = $(DESTDIR)@FVWM_DATADIR@/default-config
> config_DATA = config \
> .stalonetrayrc \

stalonetraydir = $(configdir)/.stalonetrayrc

> FvwmScript-DateTime \
> FvwmScript-ConfirmQuit \

Remove subdirs from this Makefile.am, add them to the SUBSIRS
variable, add a Makefile.am in their directory and list all files
to be installed in a variable:

  foobardir = @FVWM_DATADIR@/default-config/
  foobar_DATA = (list all files)

> FvwmScript-ConfirmCopyConfig
> 
> EXTRA_DIST  = images \
> config \
> .stalonetrayrc \
> FvwmScript-DateTime \
> FvwmScript-ConfirmQuit \

Liekwise.

> FvwmScript-ConfirmCopyConfig
> 
> install-data-hook:
>   cp -r $(srcdir)/images $(inst_location)

>   ln -sf $(inst_location)/FvwmScript-DateTime $(inst_location)/..
>   ln -sf $(inst_location)/FvwmScript-ConfirmQuit $(inst_location)/..
>   ln -sf $(inst_location)/FvwmScript-ConfirmCopyConfig $(inst_location)/..

Use "$(LN_S) -f", don't merge options.  See bin/Makefile.am for an
example how to make symlinks.

> 
> uninstall-hook:
>   rm -fr $(DESTDIR)/$(configdir)

Don't merge options, i.e. use "rm -r -f".  This command runs a
high risk of destroying user data because of the recursive delete.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

[fvwmorg/fvwm] f508f5: Fix installation and uninstallation with --program...

[Dominik Vogt]

  Branch: refs/heads/dv/fix-program-transform
  Home:   https://github.com/fvwmorg/fvwm
  Commit: f508f5f574de461e21fa5ad2d4d2d50eb75378df
  
https://github.com/fvwmorg/fvwm/commit/f508f5f574de461e21fa5ad2d4d2d50eb75378df
  Author: Dominik Vogt 
  Date:   2016-11-13 (Sun, 13 Nov 2016)

  Changed paths:
M bin/Makefile.am
M configure.ac
M doc/fvwm/Makefile.am
M fvwm/Makefile.am
M modules/FvwmAnimate/Makefile.am
M modules/FvwmAuto/Makefile.am
M modules/FvwmBacker/Makefile.am
M modules/FvwmBanner/Makefile.am
M modules/FvwmButtons/Makefile.am
R modules/FvwmCommand/FvwmCommandS.c
M modules/FvwmCommand/Makefile.am
A modules/FvwmCommandS/FvwmCommand.h
A modules/FvwmCommandS/FvwmCommandS.c
A modules/FvwmCommandS/Makefile.am
A modules/FvwmCommandS/fifos.c
M modules/FvwmConsole/Makefile.am
M modules/FvwmCpp/Makefile.am
M modules/FvwmEvent/Makefile.am
M modules/FvwmForm/Makefile.am
M modules/FvwmIconMan/Makefile.am
M modules/FvwmIdent/Makefile.am
M modules/FvwmM4/Makefile.am
M modules/FvwmPager/Makefile.am
M modules/FvwmPerl/Makefile.am
M modules/FvwmProxy/Makefile.am
M modules/FvwmRearrange/Makefile.am
M modules/FvwmScript/Makefile.am
M modules/Makefile.am

  Log Message:
  ---
  Fix installation and uninstallation with --program-transform-name.

Had to move FvwmCommandS to a different subdir to do this.

Re: fvwm3 repo (WAS: Re: Separate or common project infrastructure fvwm v2/v3.)

[Dominik Vogt]

On Sun, Nov 13, 2016 at 02:03:52PM +, Thomas Adam wrote:
> On Sun, Nov 13, 2016 at 04:30:23AM +0100, Dominik Vogt wrote:
> > On Sun, Nov 13, 2016 at 02:06:19AM +, Thomas Adam wrote:
> > > On Sun, Nov 13, 2016 at 02:43:13AM +0100, Dominik Vogt wrote:
> > > > Why on earth do we have to repeat the mistake of the past by
> > > > putting the version number in the project name *again*?  Every
> > > > other project manages backwards incompatible releases just fine,
> > > > only fvwm changes its name with each major release.  This just
> > > > complicates things, and helps nobody.  That's what configure's
> > > > binary suffix is for.
> > > 
> > > So what would you rather, and to what extent should this happen?
> > 
> > See attached patch.  The Makefile.am need some tuning because some
> > names are hard coded in install...local rules (FvwmCommand.sh,
> > FvwmCommand.pm, xpmroot*, fvwm2*, message catalogs).  It's easy to
> > firgure out; just configure with --prefix=some-private-dir, ass
> > program-suffix and program-prefix, then install and see which
> > files end up in the wrong place.
> 
> Right.  I'd forgotten that automake allowed for --program-{prefix,suffix} --
> that makes things much easier.  So I'll rejig some things and use this.
> 
> I can see there's a few things which will need adjusting.  We won't need the
> fvwm2 symlink at all since that would be misleading, surely?  The other parts
> you've identified shouldn't be too difficult to fix.

>  I'm unsure what should
> happen with the gettext files, and if they need namespacing at all.

As with my path modules don't get a suffix (unless installed in
bin/), the same concern applies to the module manpages.  It would
be confusing to have a module "FvwmButtons" with a manpage
"FvwmButtons-3.1".  But if the module name is not suffixed, there
cannot be multiple versions of the manpage installed.

> One observation I've got is:
> 
> > +transform=`echo "${program_transform_name}" | "$SED" -e 's/\\$\\$/\\$/'`
> > +PPACKAGE=`echo "${PACKAGE}" | "$SED" -e "${transform}"`
> 
> Is this not what the option '--program-transform-name=program' is doing?  See:
> 
> https://www.gnu.org/software/automake/manual/html_node/Renaming.html

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt