Switching from relative paths to absolute directory specifications in make scripts?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Switching from relative paths to absolute directory specifications in make scripts?

SF Markus Elfring
Hello,

I am fiddling with a few build scripts for another free software.


elfring@Sonne:~/Projekte/Bau/OCamlbuild> rm -f src/glob_lexer.ml && LANG=C make --no-builtin-rules V=1 src/glob_lexer.ml; LANG=C make --no-builtin-rules V=1 ~/Projekte/Bau/OCamlbuild/src/glob_lexer.ml
make: *** No rule to make target 'src/glob_lexer.ml'.  Stop.
ocamllex.opt -o /home/elfring/Projekte/Bau/OCamlbuild/src/glob_lexer.ml /home/elfring/Projekte/OCaml/OCamlbuild/lokal/src/glob_lexer.mll
55 states, 419 transitions, table size 2006 bytes


This test result seems to show that it can make a significant difference
if such a target was specified by a relative or absolute path.
(I would expect that these specifications will refer to the same file.)

Do I need to extend the software build rules a bit more here?

Regards,
Markus

_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Switching from relative paths to absolute directory specifications in make scripts?

Duane Griffin
On Thu, Jul 6, 2017 at 1:34 AM, SF Markus Elfring
<[hidden email]> wrote:
> This test result seems to show that it can make a significant difference
> if such a target was specified by a relative or absolute path.
> (I would expect that these specifications will refer to the same file.)

Keep in mind that targets are opaque strings, not references to files
as such, and hence the exact path matters. E.g. "foo", "./foo",  and
"bar/../foo" are all different targets as far as make is concerned,
even if they all resolve to the same file on disk.

> Do I need to extend the software build rules a bit more here?

Yep, you need to fix your makefile if you want it to work with both
relative and absolute paths. If you are doing complicated things,
especially if you have a modular build system with makefiles in
different sub-directories referring to the same files, you need to be
careful how you use and construct target paths so they are consistent.

Cheers,
Duane.

--
"I never could learn to drink that blood and call it wine" - Bob Dylan

_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Switching from relative paths to absolute directory specifications in make scripts?

SF Markus Elfring
>> This test result seems to show that it can make a significant difference
>> if such a target was specified by a relative or absolute path.
>> (I would expect that these specifications will refer to the same file.)
>
> Keep in mind that targets are opaque strings,

I would prefer a more convenient handling of build goals in some use cases.

I noticed once more how relevant implicit make rules can become
in this test case.


> not references to files as such, and hence the exact path matters.

The make software manages also a bit of extra background information.

How interesting can it become to filter targets if they are phony (or not)?


> E.g. "foo", "./foo",  and "bar/../foo" are all different targets as far
> as make is concerned, even if they all resolve to the same file on disk.

Can the software situation be improved any more there?


>> Do I need to extend the software build rules a bit more here?
>
> Yep, you need to fix your makefile if you want it to work with both
> relative and absolute paths.

I can adjust specific make scripts to some degree. Will it be better
to avoid the duplication of corresponding build rules?


> If you are doing complicated things, especially if you have
> a modular build system with makefiles in different sub-directories
> referring to the same files, you need to be careful how you use and
> construct target paths so they are consistent.

* Do you specify any extra explicit (non-pattern) make rules then?

* How are the chances to reduce any inconveniences there?

Regards,
Markus

_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Loading...