[jbandela1]

One of the nice things that Visual C++ has is

    #pragma comment(lib, "xxx.lib") 

You can specify it in a header file for the library. That way if you include the header file, the library mentioned will automatically get linked as long as it is somewhere in the library search path.

I have found myself wishing that GCC would also get something like this.

[Joker_vD]

I remember back when I was programming in Delphi I could link directly against a .dll, just take a function prototype from the .h file and translate it into a function declaration like this one:

    function I2C_GetNumChannels(out numChannels: Longword): FT_Result; stdcall; external 'libmpsse.dll';

and that was it; but to do this in MSVC you needed not only the .h header and the .dll itself, you also needed that stupid .lib file that had AFAYCT had literally nothing inside it except symbol entries that said "no, load it dynamically from this .dll on startup, please". So it was a rather common source of amusement for Delphi programmers that paradoxically, it was harder to link a program written in C against a DLL written in C than it was to link a program written in Delphi against a DLL written in C.

[FpUser]

Delphi made an awful lot of things incredibly easy. Com automation for example. It is just too bad Borland had fucked up.

[pjmlp]

It boggles my mind that for how hardline the WinDev is about using COM, they still fail to match Borland, nowadays Embarcadero tooling for COM.

For a brief moment they almost had it with .NET Native and C++/CX, and then, first they killed C++/CX in name of C++/WinRT (with VS tooling just like in the good old ATL days), and with UWP's deprecation, CsWinRT also fails quite short of the .NET Native experience in regards to COM.

How a OS development team that is so invested into COM APIs, fails to produce tooling better than the competition for 25 years escapes me.

[FpUser]

>"It boggles my mind that for how hardline the WinDev is about using COM, they still fail to match Borland, nowadays Embarcadero tooling for COM."

I've been in the industry for 30 years just in Canada. Have come to conclusion that software developers in their majority rarely prefer most efficient, elegant (whatever that means) ways of accomplishing things. I have a theory that being "software developer" is sort of self servant. Because of that they enjoy unneeded complexity, tooling etc. etc.

I personally have never indulged into coding for the sake of it. To me software development was always just a tool to build amazing products people / businesses would use. So I always think about product, how it will be used and how to get there with the least financial "damage" either for my own company or for a client.

[pjmlp]

I share a similar feeling, from my point of view developers are users as well, and we should enjoy similar nice workflows as regular users.

[flohofwoe]

I wish that would work for all build settings, and be standardized across compilers. Even building complex projects with platform-specific build settings could then be reduced to a simple:

    cc main.c -o bla

[AlbertoGP]

Oh, wow, I’ve been thinking for a while about implementing something similar for myself to be used with GCC/clang on Linux.

I suspected that someone might have done it before, but didn’t know of any implementation. I’ll take a closer look at Visual C++ (used it in the last millennium for work) before deciding how mine should work.

[tkuraku]

I really don't like this feature. I like knowing what and where things are linked explicitly.

[flohofwoe]

This could be handled through a --verbose flag on the linker (and maybe --dry-run).

[mathstuf]

The problem I've found is that it gives you the name…but not the path. I've ended up seeking ways to turn it off every time I've run into it.

FD: CMake developer