RFC Re: [PATCH] Shorter object file names under subdir-objects

[Thomas Martitz]

Hello Matieu,

good news: I found a solution.

Am 19.04.2017 um 12:54 schrieb Mathieu Lirzin:

> Hello,
>
> Thomas Martitz <address@hidden> writes:
>
> > Am 13.04.2017 um 14:59 schrieb Mathieu Lirzin:
> >
> > > I have not spent a long time digging through the mailing list archive,
> > > There seem to have a lot of mail related to subdir-objects past bugs
> > > which makes it hard to find the information I am looking for.  However I
> > > have found some questions which relates to the change you are proposing:
> > >
> > >    https://lists.gnu.org/archive/html/automake/2013-02/msg00051.html
> > >    https://lists.gnu.org/archive/html/automake/2003-11/msg00104.html
> >
> > Thanks for taking your time and digging through the archives. It looks
> > like there is a clear demand for the change (see also Peter Rosin's
> > reply).
>
> I agree that the way long object names appears can be confusing for
> Automake users.
>
> > > Thomas Martitz <address@hidden> writes:
> [...]
> > > > But with subdir-objects this is unecessary, since uniqueness of the
> > > > object file names
> > > > is already achieved by placing them next to the unique source files.
> > >
> > > Unfornately, I have found an example which seems to contradict that
> > > assumption.
> > >
> > > Makefile.am:
> > >    AUTOMAKE_OPTIONS = subdir-objects foreign
> > >    noinst_PROGRAMS = foo
> > >    foo_SOURCES = src/foo.c
> > >    foo_CPPFLAGS = -DVAL=0
> > >    include src/local.mk
> > >
> > > src/local.mk:
> > >    noinst_PROGRAMS += src/foo
> > >    src_foo_CPPFLAGS = -DVAL=1
> > >    src_foo_SOURCES = src/foo.c
> > >
> > > src/foo.c:
> > >    int
> > >    main ()
> > >    {
> > >      return VAL;
> > >    }
> > >
> > > With the current behavior both "src/foo-foo.o" and "src/src_foo-foo.o"
> > > are produced which allows the two executables to refer to the correct
> > > VAL.  However with the change you are proposing, only "src/foo-foo.o" is
> > > produced which is then used for both executables and make them return
> > > the same VAL.
> > >
> > > See attached patch for more details.  It adds a test which passes on
> > > current 'minor' branch but fails when applied on top of your patch.  The
> > > intent is to allow you to reproduce the issue.
> >
> >
> > The case you have brought up pretty much does the same as using %C%
> > inside local.mk. It's just that you manually applied src_ and src/
> > prefixes manually.
> >
> > Therefore, yes, this is affected by my change. The code where my
> > change is located doesn't really know whether %reldir%-feature was
> > used, or if prefixes have been manually assigned. That code only sees
> > the already-expanded variables.
> >
> > I have to say that your example seems pretty academic to me. I doubt
> > that anyone builds two equally named binaries in practice. Normally
> > you would build programs with different names, in which case this
> > effect doesn't occur, wouldn't you?
> >
> > But please be sure that understand that you take this seriously.
>
> Out of context a lot of things can be seen as weird, but since having
> programs with the same name in different directories has been considered
> valid by Automake for ages, we should expect some users to rely on that
> behavior, and we don't want to break it.
>
> > > I don't know if this is feasible to only use long names when there is an
> > > executable or library basename clash.  I suppose this would not be trivial to
> > > implement.  WDYT?
> >
> >
> > I will certainly have a look at your suggestion.


I have implemented a solution. Basically the file name truncation is 
disabled if the are programs or libs that have identical names. Please 
tell me if that's sufficient.

Best ragerds.

0001-Shorter-object-file-names-under-subdir-objects.patch
Description: Text Data

0002-Test-that-should-pass.patch
Description: Text Data

0003-Extend-subobj-objname-clash.sh-test-with-such-that-i.patch
Description: Text Data