|
Re: possible fix for PR/315: msg#00045sysutils.automake.patches
>>> "Richard" == Richard Boulton <richard@xxxxxxxxxxxx> writes: [...] Richard> I note that the information required to do the proper fix for this is Richard> available [in handle_single_transform_list] [...] Richard> The function containing this is reasonably close in Richard> calling sequence to &subobjname: Unfortunately, it is run later, inside several loops, where it seems hard to extract. Besides, it's not complete: you only know whether the single variable currently processed by &handle_single_transform_list will involve per-target flags. Duplicating object variable at this level will not work on: baz_SOURCES = $(foo) foo_SOURCES = $(foo) foo_CXXFLAGS = -mumble foo = a.c $(bar) bar = b.cc we can detect that c.cc requires foo_CXXFLAGS in one case, hence generate am_object_1 = b.o # For baz am_object_2 = foo-b.o # For foo but when processing foo we don't know that foo_CXXFLAGS is involved, so will probably define am_object_3 = a.o $(am_object_1) *and* am_object_3 = a.o $(am_object_2) (and output only the last definition, I guess). Before sending this patch, I tried to make a function to answer the question "is this target using per-target flags?". This means - expanding the {,dist_,nodist}{,EXTRA}*_SOURCES recursively - applying suffix rules to all people, gathering all languages used - looking for flags definition for each language I stopped when I realized I was duplicating too much code from &handle_single_transform_list :( Now, there might be another way. That would be to define the am_object_N variable after &handle_single_transform_list as run. This looks very simple to do; maybe even simpler than what we have now: Let's forget about substitutions, targets, and per-target flags. Basically, we just need am_object_N variables which are unique for their *content*. If we define them after &handle_single_transform_list has run, we know the content and can check whether there is a variable we can reuse, or if we need to create another one. I'll try to do that tonight. Thanks! -- Alexandre Duret-Lutz |
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| Previous by Date: | Re: possible fix for PR/315: 00045, Richard Boulton |
|---|---|
| Next by Date: | FYI: depout.m4 adjustment for post-processed Makefile.ins: 00045, Alexandre Duret-Lutz |
| Previous by Thread: | Re: possible fix for PR/315i: 00045, Richard Boulton |
| Next by Thread: | Re: possible fix for PR/315: 00045, Alexandre Duret-Lutz |
| Indexes: | [Date] [Thread] [Top] [All Lists] |
| News | FAQ | advertise |