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 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.)

[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]

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.)

[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]

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.)

[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.)

[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 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

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

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.)

[Thomas Adam]

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?  If you don't
have the time to do the work, at least have the courtesy to say so and provide
a list of things you want, and it'll get done.  But to keep going silent for a
while, coming back, and then bemoaning the state of things because you weren't
around, and/or didn't get asked, and/or things werent done how you would have
wanted, isn't how projects are run, or indeed, *will not* be run for as long
as I am involved with them.

> 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).

It's all a little bit "moan, moan, moan" coming from you, with there being
little evidence of anything actually wrong, other than you don't like
something.  So far, I've been kind.  So far, I've been courteous and polite in
helping you and explaining all that I can.  But I cannot work with just that
alone, Dominik.  I can't help *you* or give assistance when the rhetoric
you're throwing out is intangible.  I've just _told_ you how you can
accomplish certain tasks.  If you actually have something sensible which you
need help with, then by all means ask me for help if you need it.  But please
stop whinging.

> By the way, everybody else would call their versions fvwm-2 and
> fvwm-3, and that's what I'll do, starting now.

So what I want from you is a list of things which aren't correct.  You say you
want "fvwm-2" and "fvwm-3".  Fine, I don't mind what it's called, provided
some choice is made.

-- Thomas Adam