[build] relative vs absolute
Hi all. I have a question which is somewhat Boost-related and somewhat general. I've looked at the build system (i.e, Jam files) and noticed that most of time, the directories (include directories, link directories) are specified in absolute format - $(BOOST_ROOT)/whatever. However, not all of them are absolute. Some are relative - ../../../whatever. Other parts of the Boost tree, such as the html files, contain relative paths. My question is: shouldn't there be a uniform way - absolute or relative? And if so, what would it be? My opinion is that relative is superior, because is makes it possible to checkout several instances of the tree (several branches, or even several instances of head) to separate parts of the disk and work on all of them as needed, without mangling with environment variables. What I mean is that requiring to change environment variables is burdensome and errorprone (I can easily execute bjam from directory X, while BOOST_ROOT points to directory Y, which will create a disaster). What is your opinion regarding this in repect to Boost, and in respect to other projects in general? Many thanks for your time, Yuval
"Yuval Ronen" <ronen_yuval@yahoo.com> writes:
Hi all.
I have a question which is somewhat Boost-related and somewhat general.
I've looked at the build system (i.e, Jam files) and noticed that most of time, the directories (include directories, link directories) are specified in absolute format - $(BOOST_ROOT)/whatever. However, not all of them are absolute. Some are relative - ../../../whatever. Other parts of the Boost tree, such as the html files, contain relative paths.
Actually all the paths are relative. $(BOOST_ROOT) expands to a relative path like ../../.. that is adjusted to a new appropriate value in each Jamfile. -- Dave Abrahams Boost Consulting www.boost-consulting.com
I've looked at the build system (i.e, Jam files) and noticed that most of time, the directories (include directories, link directories) are specified in absolute format - $(BOOST_ROOT)/whatever. However, not all of them are absolute. Some are relative - ../../../whatever. Other parts of the Boost tree, such as the html files, contain relative paths.
Actually all the paths are relative. $(BOOST_ROOT) expands to a relative path like ../../.. that is adjusted to a new appropriate value in each Jamfile.
Why is this so? What purpose does it serve, if I may ask. Why not just put the relative path in the files? Will this be useful for other projects? Thanks again.
"Yuval Ronen" <ronen_yuval@yahoo.com> writes:
Actually all the paths are relative. $(BOOST_ROOT) expands to a relative path like ../../.. that is adjusted to a new appropriate value in each Jamfile.
Why is this so? What purpose does it serve, if I may ask. Why not just put the relative path in the files?
You can move the Jamfiles around the Boost project without concern for where they are. Also, when you're deep in a project like libs/python/test, it's much clearer to write $(BOOST_ROOT)/whatever than ../../whatever. Can you tell at a glance what the latter refers to?
Will this be useful for other projects?
Sorry, I don't understand the question. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Why is this so? What purpose does it serve, if I may ask. Why not just put the relative path in the files?
You can move the Jamfiles around the Boost project without concern for where they are. Also, when you're deep in a project like libs/python/test, it's much clearer to write $(BOOST_ROOT)/whatever than ../../whatever. Can you tell at a glance what the latter refers to?
I see.
Will this be useful for other projects?
Sorry, I don't understand the question.
Forget about it. It's way off topic, and actually, it was a stupid question to begin with. I really appreciate you spending your time answering my questions, Yuval
"David Abrahams" <dave@boost-consulting.com> wrote in message news:ufywjju4b.fsf@boost-> > I've looked at the build system (i.e, Jam files) and noticed that most of
time, the directories (include directories, link directories) are specified in absolute format - $(BOOST_ROOT)/whatever. However, not all of them are absolute. Some are relative - ../../../whatever. Other parts of the Boost tree, such as the html files, contain relative paths.
Actually all the paths are relative. $(BOOST_ROOT) expands to a relative path like ../../.. that is adjusted to a new appropriate value in each Jamfile.
I'd like to ask one more question, if possible. How does it know how to expand $(BOOST_ROOT)? If I'm standing in C:\libraries\boost_1_32_0\libs\python\test, for example, how can it possibly know that "$(BOOST_ROOT)" is "../../.."? I can't think of any algorithm that can reliably determine this. What am I missing?
"Yuval Ronen" <ronen_yuval@yahoo.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:ufywjju4b.fsf@boost-> > I've looked at the build system (i.e, Jam files) and noticed that most of
time, the directories (include directories, link directories) are specified in absolute format - $(BOOST_ROOT)/whatever. However, not all of them are absolute. Some are relative - ../../../whatever. Other parts of the Boost tree, such as the html files, contain relative paths.
Actually all the paths are relative. $(BOOST_ROOT) expands to a relative path like ../../.. that is adjusted to a new appropriate value in each Jamfile.
I'd like to ask one more question, if possible. How does it know how to expand $(BOOST_ROOT)? If I'm standing in C:\libraries\boost_1_32_0\libs\python\test, for example, how can it possibly know that "$(BOOST_ROOT)" is "../../.."? I can't think of any algorithm that can reliably determine this. What am I missing?
BOOST_ROOT is registered as a "path global" in the top-level Jamrules file: path-global BOOST_ROOT : . ; Boost.Build simply adjusts its value appropriately before loading each Jamfile. HTH, -- Dave Abrahams Boost Consulting www.boost-consulting.com
I'd like to ask one more question, if possible. How does it know how to expand $(BOOST_ROOT)? If I'm standing in C:\libraries\boost_1_32_0\libs\python\test, for example, how can it possibly know that "$(BOOST_ROOT)" is "../../.."? I can't think of any algorithm that can reliably determine this. What am I missing?
BOOST_ROOT is registered as a "path global" in the top-level Jamrules file:
path-global BOOST_ROOT : . ;
Boost.Build simply adjusts its value appropriately before loading each Jamfile.
And how is this Jamrules file found? The only thing I can think of is this: Wherever (in terms of directory) I'm invoking the build, the algorithm is to go up the directory tree until a file by the name of "Jamrules" is found, and then do what it says. Is this correct?
Yuval Ronen wrote:
And how is this Jamrules file found? The only thing I can think of is this: Wherever (in terms of directory) I'm invoking the build, the algorithm is to go up the directory tree until a file by the name of "Jamrules" is found, and then do what it says. Is this correct?
http://www.boost.org/tools/build/v1/build_system.htm#jamrules http://www.boost.org/more/mailing_lists.htm#jamboost -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
"Yuval Ronen" <ronen_yuval@yahoo.com> writes:
I'd like to ask one more question, if possible. How does it know how to expand $(BOOST_ROOT)? If I'm standing in C:\libraries\boost_1_32_0\libs\python\test, for example, how can it possibly know that "$(BOOST_ROOT)" is "../../.."? I can't think of any algorithm that can reliably determine this. What am I missing?
BOOST_ROOT is registered as a "path global" in the top-level Jamrules file:
path-global BOOST_ROOT : . ;
Boost.Build simply adjusts its value appropriately before loading each Jamfile.
And how is this Jamrules file found? The only thing I can think of is this: Wherever (in terms of directory) I'm invoking the build, the algorithm is to go up the directory tree until a file by the name of "Jamrules" is found, and then do what it says. Is this correct?
Basically, yes. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (3)
-
David Abrahams -
Rene Rivera -
Yuval Ronen