Should I Rebuild a Dependent Lib After System Update

Should i rebuild a dependent lib after system update?

This is why package systems exist.

If your libhell binary library is dynamic library (that is a libhell.so shared object, with position independent code) and if the dependency libssl-dev didn't change its API (e.g. if its version number didn't change), then you don't need to recompile and reinstall your libhell.

If you feel that your libhell depends upon a changed feature (or data) of libssl-dev then you should recompile it.

Better recompile your libhell more often than needed.

See also the Program Library Howto

Why should I recompile an entire program just for a library update?

If the signatures of the functions involved haven't changed, then "rebuilding" the program means that the object files must be linked again. You shouldn't need to compile them again.

An API is contract that describes the interface to the public functions in a library. When the compiler generates code, it needs to know what type of variables to pass to each function, and in what order. It also needs to know the return type, so it knows the size and format of the data that will be returned from the function. When your code is compiled, the address of a library function may be represented as "start of the library, plus 140 bytes." The compiler doesn't know the absolute address, so it simply specifies an offset from the beginning of the library.

But within the library, the contents (that is, the implementations) of the functions may change. When that happens, the length of the code may change, so the addresses of the functions may shift. It's the job of the linker to understand where the entry points of each function reside, and to fill those addresses into the object code to create the executable.

On the other hand, if the data structures in the library have changed and the library requires the callers to manage memory (a bad practice, but unfortunately common), then you will need to recompile the code so it can account for the changes. For example, if your code uses malloc(sizeof(dataStructure)) to allocate memory for a library data structure that's doubled in size, you need to recompile your code because sizeof(dataStructure) will have a larger value.

Do I always need to rebuild the project containing references to sub project's dll, if sub projects are updated?

You should rebuild everything, yes. When you change one of the class libraries, that could subtly change how the code is called. There are obvious changes like removing a method that your web site is relying on, but there are sneakier ones like adding an overload - so that the code will still compile, but have a different effect.

I don't know of any way to tell Visual Studio not to do a rebuild when a dependency changes... I would personally look at finding a way to make the overall build faster instead.

If you're doing a lot of work in the class libraries and you don't actually need the web site for the moment, you could always unload that project until you need to run the whole site again.

Do I have to recompile my application when I upgrade a third party jar?

If the API changes, you should recompile even if you don't need to make any changes in your source code. If the API hasn't changed, you don't need to recompile.

The reason for the "even if you don't need to make any changes" is that some source-compatible changes may not be binary compatible. For instance, suppose you are currently calling:

public void foo(String x)

and in a later version this is changed to:

public void foo(Object x)

Obviously your code will still compile, but the method it resolves the call to will change.

This is a bit of an edge case, of course. Basically, so long as you know when the API changes, you should be okay.

Rebuild dependant target after a custom target runs

[This answer's central method comes from @KamilCuk's answer in the comment of the question].

The trick is to use one of:

• Set the LINK_DEPENDS property on the downstream target (main_prog in the example) - this means if the file in this property changes, a re-link will be performed.
• Set the OBJECT_DEPENDS on every source used for main_prog.

In my case, because the ${COMPILER_OPTS_FILE} affects every file's compilation, I needed the OBJECT_DEPENDS method. If you do this you don't really need LINK_DEPENDS since you'll recompile your sources and re-link anyway, but I did both for clarity of meaning. In theory you could engineer a situation where the linker command file changes, but not the compiler opts, in which case you might miss a re-link.

In my case, I needed to do this for not only main_prog but also all the other libraries main_prog used, so I stored the linker command files and the compiler opts file as target properties on the platform_libs target:

set_property(TARGET platform_libs
    PROPERTY MY_LINKER_CMD_FILE ${LINKER_CMD_FILE}
)
set_property(TARGET platform_libs
    PROPERTY MY_COMPILER_OPTS_FILE ${COMPILER_OPTS_FILE}
)

This means it's easy to pull them out later, without having to know the exact file names (or even have access to the variables themselves):

# Retrieve the previously-stored options
# To do this, we only need the target name and the (fixed) property name
get_target_property(MY_LINKER_CMD platform_libs MY_LINKER_CMD_FILE)
get_target_property(MY_COMPILER_OPTS platform_libs MY_COMPILER_OPTS_FILE)

set_target_properties(main_prog PROPERTIES
    LINK_DEPENDS ${MY_LINKER_CMD}
)

# Also set as the linker cmd on the linker command line
# This depends on the linker, for GCC it's -Wl,T<file>
target_link_libraries(main_prog PRIVATE
    -Wl,-T${MY_LINKER_CMD}
)

# these are the sources that depend on the opts file
get_target_property(MAIN_SRCS main_prog SOURCES)

# set the dependency of source files on platform_libs
set_property(SOURCE ${MAIN_SRCS}
    PROPERTY OBJECT_DEPENDS ${MY_COMPILER_OPTS}
)
# Set as a compiler opt file
# For GCC: @<opt_file>
target_compile_options(${TARGET_TO_COMPILE} PRIVATE
    @${MY_COMPILER_OPTS}
)

# make sure the platform_libs is a dep
# or the compiler opts and linker files won't be generated
add_dependencies(main_prog platform_libs)

Notably, in this Cmake code, the project names main_prog and platform_libs can be variables, and then you can make the whole thing into a function that just needs those two project names. This makes it easy to reuse the code for compiling libraries against platform_libs library.

If I update an RPM, do I have to rebuild all RPMs that are based on it

Yes and no. There are two kind of dependencies: generated and implicit ones.

If you speak about C libraries, then rpmbuild generate dependencies like this:

$ rpm -R bash
...
libdl.so.2()(64bit)
...

And when the package which provides this library is updated, but it keeps the same SONAME, i.e., the same binary interface, then you do not need to rebuild the package which use it (in this example bash). But when there is SONAME bump and the package suddenly provides libdl.so.3, then you have to rebuild the package which requires it.

If the dependencies are something else, then you do not need to rebuild the package. For example package firefox requires bash, but it is fine with any version. So when bash is being updated, you do not need to rebuild firefox.

Sometime it happens that you depend on something (python-2.x) and it got very major upgrade (python-3.x), then you need to rebuild the package which requires it. In these rare cases you usually know about it in advance as you have to not only rebuild the package but rewrite the code of the application itself. E.g. migration from python2 to python3 is non-trivial.

Quick'n'dirty tip for most case scenarios: unless DNF/YUM tell you that you have broken dependencies, you do not need to rebuild your package.

Xcode not rebuilding app when source file updated in dependent static library

I had originally searched SO without success, but I must not have phrased my searches properly. However, while writing up my question, the "Similar Questions" list offered much better results, and I was able to find a workaround. In brief:

• select the library in the Project Navigator
• find the location in the File Inspector; it is probably "Relative to Group"
• change it to "Relative to Build Products"

This fixed the issue in my test case; now the application is correctly rebuilt whenever the library's source code is modified. I did not find it necessary to manually edit the project.pbxproj file as suggested.

I would still claim this is a bug in Xcode, but at least now I have a workaround.

How to rebuild a Third-Party library in Xcode 4.5 GM

I had a similar problem with one of my static libraries. Basically, you will need to have the library recompiled to support armv7s, but in the meantime, you can remove that requirement from the build settings.

In your project settings, look for Architectures and I'm guessing it says, "Standard (armv7, armv7s)" Remove it and replace with "armv7" and your project should compile.

Automatically rebuild dependencies in Qt Creator

I have used CONFIG += ordered, DEPENDPATH and PRE_TARGETDEPS to get rid of the same problems. It works for me on linux and on win with MSVC. Try it.

in your project pro file add:

CONFIG += ordered

P.S.: your lib should be listed first. Like :

SUBDIRS += \
    lib \
    app \
    tests

in your exe .pro file add this with correct paths:

DEPENDPATH += $$PWD/../lib
PRE_TARGETDEPS += $$OUT_PWD/../lib/liblib.a

More options and flags is to be found here

---

Related Topics