I know I'm in bad subforum but couldn't find any more suitable. So, I'm writing a simple static library. I'm also writing an application that uses this library. I modify lib's and app's code all the time. The problem is that if I want to have an always updated lib used in the application, I need to recompile the whole application. I don't quite understand this. If lib is recompiled, why then doesn't the application use it, but uses some old "version"? I really don't want to recompile the whole application after every single change in lib's code. What can I do to speedup my development process? :)

A static library is linked in to the executable at build time. If the library changes, the application must thus be relinked. If part of the code changes to the library included changes to any headers that the application's source files include, those source files will rebuild as well. This is just how C++'s compilation model works.

Moving to General Programming.

Quote:
If the library changes, the application must thus be relinked.

Mhm, it's first time for me to play with static libraries and I had missed Build -> Project Only -> Link Only option before :). So I don't really have to recompile the project, just relink it. However, let's say I'm linking with 100 libs (it's hypothetical situation) and that I would like to relink only one of them. Is sort of things like this possible?
I'm just considering improving my prodictivity when handling applications and libs separately :).

Quote:
Mhm, it's first time for me to play with static libraries and I had missed Build -> Project Only -> Link Only option before :).

If you do this, and you have changed headers from the library, you will likely experience strange and interesting bugs and crashes.

Quote:
However, let's say I'm linking with 100 libs (it's hypothetical situation) and that I would like to relink only one of them. Is sort of things like this possible?

Yes, but...

Quote:
I'm just considering improving my prodictivity when handling applications and libs separately :).

...in general it is best to just let the build system do its work. It's doing what it needs to do.

Hmmm... if rebuilding is the best way then it's quite a "slow" solution to the problem. Let's consider two cases:

1. Lib has 100 files, app has 100 files. I changed something in lib file - I recompile this one file within the lib. Now I need to recompile the whole application (100 files) just becuase I had recompiled one file from the lib ?(!)
2. Lib and app are merged - one project containing 200 files. Change in one cpp file from the "lib" doesn't involve recompiling the app ("it's" 100 files)

Note that I'm mostly talking about modifying lib's cpp files, not headers. It's clear that when I modify headers I need to recompile the app's cpp files that are including this header. But when I make changes in lib's cpp files then I only need to relink app with that lib, right?

Quote:Original post by maxest

1. Lib has 100 files, app has 100 files. I changed something in lib file - I recompile this one file within the lib. Now I need to recompile the whole application (100 files) just becuase I had recompiled one file from the lib ?(!)
2. Lib and app are merged - one project containing 200 files. Change in one cpp file from the "lib" doesn't involve recompiling the app ("it's" 100 files)

Static libs don't change. They are a distribution mechanism, a bundle. Typical environment will use a versioned lib against which everyone else developers. Upgrading this version is A Big Thing(tm).

Upgrading versions might be a part of nightly or weekly build. At least for projects of such scale.

If changing stuff, working with libs doesn't help. Libs are for stuff that does not change.

Quote:But when I make changes in lib's cpp files then I only need to relink app with that lib, right?

Lots of stuff, especially since compilers these days do link-time optimization.

Naive linker would just put stuff together, but it still needs to do a lot of work across entire result to mangle the symbols. It has a lot to do with how executable images are laid out and how the code is interconnected, the memory model, segments, etc... But if one symbol increases in size by one byte, it can cause possibly require all addresses across entire executable to change.

Related reading: Courgette algorithm.


In theory, a special version of compiler could indeed just replace a symbol, and patch what is needed. But since linker is a standalone process, all information that would be needed (we're talking potentially gigabytes here) is discarded each time linker process exits.

Let's get this staight. If I really need to recompile the whole project after making changes in the lib, then does it make sense to develop the library separately? Maybe this would really be better to merge the app and the lib and have this 200 files in one project. This would be much more effective.
But how then professional projects handle this? They must be using some additional test applications to test the lib they are developing (and constantly changing). How do they manage the development process?

To be honest: Where is the problem about recompiling/linking? If i change a .cpp in one of my projects static libraries and recompiling the solution the linking and codegeneration process takes 1-2 minutes. And most of my projects are a lot bigger than 100 files in lib and 100 files in the project. So there aint a problem with the time.

Quote:Original post by maxest

But how then professional projects handle this? They must be using some additional test applications to test the lib they are developing (and constantly changing). How do they manage the development process?

Usually, each team will be working on its own part. They will depend on other libraries, but specific version of them. Periodically, as teams progress, they will release a new version. Time is then allocated to integrate and test the new version, submit patches, etc.

However, this applies to the case mentioned above - hundreds of libs (aka, 1MLOC+ project, 50-500 developers, release schedules, planning and architecture). The API must be nailed pretty accurately from the beginning, since everyone else will be depending on it. Development is plannet, either in sprints or via other methods, changes are published once every few weeks, perhaps even months, libraries are released at a certain specific schedule - this allows everyone else who depends on it to plan in advance for integration problems. "always changing" argument no longer applies.


A lib should encompass self-contained functionality. SDL, OGL, ... Something rounded and well defined. Each such lib then comes with battery of standalone tests that are ran in isolation.


Unless you have plans to release the library as a standalone, then they aren't really needed, should be part of automated build infrastructure (cluster/nightly build), or should not be modified.