 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 27/05/2016 01:39 PM, clipka wrote:
> Am 27.05.2016 um 12:31 schrieb scott:
>>> I can't believe I've just spent an entire day writing Makefiles... At
>>> this rate, it would almost be simpler to just write a loop to compile
>>> every source file in every directory and then link them all! But, alas,
>>> it turns out that you have to actually link them in the right order, or
>>> it doesn't work.
>>
>> Isn't there some tool to do that automatically?
>
> Absolutely. It is called "make", and needs a Makefile to work ;)
LMAO! :-D
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 27/05/2016 02:23 PM, scott wrote:
> Oh, what you can use make to make a makefile? Sounds like some IOCCC
> entry...
Weirdly, Make actually has implicit rules for how to make the Makefile
itself... If you run it in debug mode, you can see it "considering"
whether your Makefile is up-to-date or not.
I have no idea what these rules *are*, mind you... Perhaps it's looking
for a Makefile.am to run AutoMake on or something?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 27/05/2016 04:10 PM, dick balaska wrote:
> It's weird that in 2016 a 1980s program is still in charge of assembling
> large swaths of code. Ant /tried/ to take over, but that's even worse.
Make is a nice *concept*... sadly, the *implementation* leaves something
to be desired.
(I want to find the person who decided to use tabs as part of the
language syntax and BEAT HIM TO DEATH! >_< My text editor is rightly
configured to strip all tabs and turn them to spaces, but then noooo...
As soon as you want to edit a Makefile, you have to turn that off.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 27/05/2016 04:36 PM, Le_Forgeron wrote:
> Actually you can ask gcc/g++ to output the dependencies on sources files. Then you
can have them read back by "make".
Yes, this is the main thing I did.
Originally, the Makefile had one entry for every source file in the
entire project, some (but not all) listing the header files they depend
on. (Hey, at least the exact compilation command was a variable!)
I replaced that with a rule that says how to build any object file from
a source file. That crunched the file size down to a fraction of its
former self. I also made G++ spit out dependency information that then
gets included back into the Makefile. Our CI server probably won't care,
but it'll help the next poor sod who tries to build it by hand.
Finally, I wrote some crazy Make macro [yes, Make has macros] that
generates a list of all the object files in a folder. Before they exist.
So that I can depend on them.
...and then I did it all over again, since apparently SO files have to
be built with -fPIC, whatever that does...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
On 27/05/2016 18:54, Orchid Win7 v1 wrote:
> Weirdly, Make actually has implicit rules for how to make the Makefile
> itself... If you run it in debug mode, you can see it "considering"
> whether your Makefile is up-to-date or not.
>
> I have no idea what these rules *are*, mind you... Perhaps it's looking
> for a Makefile.am to run AutoMake on or something?
'make -p' dumps default rules & vars. 'info make' is your friend.
jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 27/05/2016 07:09 PM, jr wrote:
> hi,
>
> On 27/05/2016 18:54, Orchid Win7 v1 wrote:
>> Weirdly, Make actually has implicit rules for how to make the Makefile
>> itself... If you run it in debug mode, you can see it "considering"
>> whether your Makefile is up-to-date or not.
>>
>> I have no idea what these rules *are*, mind you... Perhaps it's looking
>> for a Makefile.am to run AutoMake on or something?
>
> 'make -p' dumps default rules& vars. 'info make' is your friend.
I don't have access to any Linux machines that have man or info
installed. Our build process strips it to save space...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 27/05/2016 19:51, Orchid Win7 v1 a écrit :
> On 26/05/2016 08:28 PM, Le_Forgeron wrote:
>> Le 26/05/2016 20:11, Orchid Win7 v1 a écrit :
>>> I also enjoy how if you try to link an executable, it whines about unresolved
symbols, but if you link an SO file, it's NOT considered an error to have missed half
of the necessary object files... (!)
>>
>> Shared lib (.so) are allowed to be completed later by other libs, or even the
loading binary.
>
> Presumably this requires the executable to load everything in exactly the right
order though?
One ring to rules them all.
Do not make a lib per folder, make a single lib.
Just like your meal ends up in your stomach, it will nourish you.
Later you can learn cooking and try to have separate plates, including a sweet
dessert, if the code allows such split.
But sometime code is just a spaghetti meal and nothing else.
>
>> It's at runtime that you will get your problems.
>
> Indeed. This is what I feared... So at some point, when the program is running, it
will suddenly segfault for no apparent reason, and it will be mathematically
impossible to ever determine why. Great.
No, symbol resolution is done at the start of the program (unless you start using
black magic for delayed resolution... you can even load a shared library later, to
resolve a symbol that came from processing some text data... but it's not for the
light hearted and is
often not portable).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 27/05/2016 19:59, Orchid Win7 v1 a écrit :
> On 27/05/2016 04:36 PM, Le_Forgeron wrote:
>
>> Actually you can ask gcc/g++ to output the dependencies on sources files. Then you
can have them read back by "make".
>
> Yes, this is the main thing I did.
>
> Originally, the Makefile had one entry for every source file in the entire project,
some (but not all) listing the header files they depend on. (Hey, at least the exact
compilation command was a variable!)
>
> I replaced that with a rule that says how to build any object file from a source
file. That crunched the file size down to a fraction of its former self. I also made
G++ spit out dependency information that then gets included back into the Makefile.
Our CI server probably
> won't care, but it'll help the next poor sod who tries to build it by hand.
>
> Finally, I wrote some crazy Make macro [yes, Make has macros] that generates a list
of all the object files in a folder. Before they exist. So that I can depend on them.
>
> ...and then I did it all over again, since apparently SO files have to be built with
-fPIC, whatever that does...
you can build .so and .a with the same .o (as -fPIC is not a problem for .a), one
compilation, two forms of library, if you really need them.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 2016-05-27 13:56, also sprach Orchid Win7 v1:
> (I want to find the person who decided to use tabs as part of the
> language syntax and BEAT HIM TO DEATH! >_< My text editor is rightly
> configured to strip all tabs and turn them to spaces, but then noooo...
> As soon as you want to edit a Makefile, you have to turn that off.)
And my editor is rightly configured for tabs to be preserved at 4 spaces.
Which means we can't co-mingle python code either.
--
dik
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 2016-05-27 14:10, also sprach Orchid Win7 v1:
> I don't have access to any Linux machines that have man or info
> installed. Our build process strips it to save space...
wow. that's ... poor.
--
dik
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
