[bug #54395] Regression in validation of GNU-style long names in archives

[anonymous]

Follow-up Comment #1, bug #54395 (project make):

A better example, which shows that my initial patch was still not correct:


# Both member names > 16 characters long
default: foo.a(long1) foo.a(long2)

(%): %
ar rU $@ $%

long%:
touch $@


Attaching a new patch that makes this work too.


(file #44643)
___

Additional Item Attachment:

File name: 0001-Fix-validation-of-long-names-in-archives.patch Size:2 KB


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: use of math.h / libmath discouraged?

[Eddy Petrișor]

joi, 26 iul. 2018, 19:42 Brian Vandenberg  a
scris:

> Wouldn't profiling information help?
>> See details and link to code with 3.81 that does this at:
>>
>
> Yes, it would.  I was unaware of that issue.
>
> It looks as though that feature never made it in [unfortunately].  If it
> were added, was present in a default build and there were a way to
> enable/disable it dynamically then what I'm proposing here wouldn't be much
> of an improvement (if any).
>

Yes, unfortunately, I did not get any feedback from the community except
the initial one suggesting some unusable, IMO, output, while I was focusing
on the usability of the feature without involving a long chain of external
tools (raw output and LibreOffice Calc were enough in both my proposals).

There were since other minor portability issue which I was planning to
address once the main design was agreed, but that did not happened, stated
using another build tool which had profiling info and I lost interest in
improving GNU make.

The enabling of the profiling feature was triggered by the passing of the
command line parameter and was done at rule level and start and end of the
make process. Finer granularity was not considered.


>
> When I say "enable it dynamically" I mean something along these lines:
>
> $(profile_options ...formatting/level/etc goes here...)
>> # or
>> .PROFILE_OPTIONS := ...ditto...
>> $(enable profiling)
>> ...some expressions not at recipe scope...
>> $(disable profiling)
>> $(profile some expression)
>> .RECIPEPREFIX := >
>> some_target:
>> > $(profile ${CC} ${FLAGS} ${<} -c -o ${@})
>
>
> In lieu of that, what I'm proposing is worth adding in that it's not
> difficult to use, its footprint is small and can give insight that's
> otherwise difficult to glean.
>

I have no problems with being able to profile a build, I know the pain of
managing a large build system and having no insight into the performance
bottle necks.
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #54395] Regression in validation of GNU-style long names in archives

[anonymous]

URL:
  

 Summary: Regression in validation of GNU-style long names in
archives
 Project: make
Submitted by: None
Submitted on: Fri 27 Jul 2018 03:37:03 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

Philipp Wolski  reported in
https://bugs.debian.org/904749 that make sometimes fails to see archive
members.

A simple example is:

# BEGIN
default: foo.a(long)

(%): %
ar rU $@ $%

long:
touch $@
# END

make will always want to remake the archive member because ar_scan() doesn't
consider its name to be valid.

I've attached a patch that fixes this example; I will ask Philip to test it as
well.




___

File Attachments:


---
Date: Fri 27 Jul 2018 03:37:03 PM UTC  Name:
0001-Fix-validation-of-GNU-style-long-names-in-archives.patch  Size: 3KiB  
By: None



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make