public inbox for [email protected]
help / color / mirror / Atom feedFrom: Chapman Flack <[email protected]>
To: Kartik Ohri <[email protected]>
Cc: [email protected]
Subject: Re: the ScriptingMojo
Date: Wed, 26 Aug 2020 01:09:19 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAASLQ4P47TNiEsuj3ga-vuYeCSBJZmHrPM-49E-X=0T5RTmhKw@mail.gmail.com>
References: <CAASLQ4Mva7dAXiS_c9OLhV4VzNHF=XNKJosuS5gtZTB6b4TW1Q@mail.gmail.com>
<[email protected]>
<CAASLQ4PEgo5Nj0EVsOfGoB96dQFXfFYxrrB0rS1wdad7x_E5fA@mail.gmail.com>
<CAASLQ4OowXOmnbbbT0Wh1ZkB4h=6JQfC61ojmN07EYnO0QCcow@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CAASLQ4MBWQeFLdAPNcsgcpLyekU5X=ExQUuGgE49AUFdEYJr8g@mail.gmail.com>
<[email protected]>
<CAASLQ4P5oEx0DLoDLEOAkZSwffU2eS2+NKbevgYqpknHGucaTw@mail.gmail.com>
<[email protected]>
<CAASLQ4Nr3MPQuZziVU+89ULZ=BgQjaPPnCLsyPR3mhW-eWoOBw@mail.gmail.com>
<[email protected]>
<CAASLQ4PkP017rtyUswKO_TCiNmnica-nrQHBgggFw-U_9MstUg@mail.gmail.com>
<[email protected]>
<CAASLQ4P47TNiEsuj3ga-vuYeCSBJZmHrPM-49E-X=0T5RTmhKw@mail.gmail.com>
On 08/26/20 00:44, Kartik Ohri wrote:
> Also, I had another question: is there any particular reason that compiling
> and linking should
> be two different commands. To me it appears to be another one of nar maven
> quirks.
> Compilers by default compile and link in a single step. It seems nar maven
> overrides it due to
> reason. Since, there is no configuration to suggest that this is desired I
> am a bit confused.
> Do we want to compile and link in different steps ?
Yes ... because not only is it done by the nar-maven-plugin (which is not
what we want to imitate), it is also done that way by the PGXS makefiles
(which are what we want to imitate). In fact it has been the usual practice
for about as long as there have been makefiles.
One reason is that compiling C programs is a kind of local activity.
Each .c file is transformed into a .o file, without needing to know
very much about the others. (What little it does need to know, it
gets from .h files.)
Conceptually, it's a different operation once you have all of those .o
files and you want to edit and link all of them together into some kind
of binary image with the references resolved. On top of that, there are
choices in what kind of result to produce. A standalone executable?
A static library? A dynamic library? A loadable plugin? (The Mac OS
linker really makes a distinction between a regular dynamic library
and a plugin. The unresolved references in a dynamic library have to
be findable in the other libraries given as its dependencies. For a
plugin, the assumption is they will be findable in the program that
the plugin gets loaded into. The Mac linker actually checks that at
link time, which is why there is a -bundle_loader option added in
the Mac OS profile in pljava-so.)
Even when you can just pile all the compiling and linking options onto
one gcc command line, that still is just the gcc wrapper command being
clever and sorting the options out and running the preprocessor and
compiler and then the linker. But for clarity in makefiles, it is very
common to separate the rules for compiling the components from the rules
for linking the final product.
Regards,
-Chap
view thread (78+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: the ScriptingMojo
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox