celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Broekhuis <a.broekh...@gmail.com>
Subject Re: Celix 0.0.1 release and Native-OSGI
Date Tue, 07 Aug 2012 09:27:03 GMT

> I have created an alternative for making bundles which does not
> depends on CPack.
> IMO making bundles with CPack is messy, because it also results in
> extra and often unwanted install rules and
> I think that is preferable to have a make install command which works
> as expected and not rely on user typing commands like:
> "cmake -DCOMPONENT=framework -P cmake_install.cmake".

"As expected" is quite a stretch to say. Please don't confuse CMake with
autotools/configure. They are 2 separate things.

> I placed the logic for creating bundles without CPack in
> cmake/Bundling.cmake.
> You can activate the bundling logic by changing the
> cmake/Include.cmake file so that it will include Bundling.cmake
> instead of Packing.cmake. In
> device_access/device_access/CMakeLists.txt there are some - commented
> out - example commands for adding files and marking a bundle for
> install.
> Any comment on this would be great.

Even though I don't mind having an alternative, I do have some objections
at this point of time. We basically said to work towards a first release
and not make any big changes. Imo this is a big change.

There are also several options missing, eg how can files be added? Besides
that, the functions look overly complicated for such a simple thing. I'll
have to look into detail to verify them.

You tried to replace a basic function of CMake/CPack. Although I agree that
currently the "make install" is a little awkward, for now I'd like to
suggest to keep it the way it is.

One other minor remark, you used FILE(GLOB..., to include header files.
They are probably in some more places. For file inclusion it is ok, but
take caution when doing the same to add source files. Using a GLOB breaks
the dependency tracking of CMake.

To summarize,

I am ok with an alternative, but the macro's/functions should be more
inline with all other macros (bundle_add uses a very strange way for
parsing arguments). Also, these things require a discussion to get all
details clear. Eg what does it support now and what should it support in a
new solution? Let's please have that discussion before we start changing
things. These are not minor changes!

Finally, I don't think this is the right time to start messing with the
For both of us available time is limited, so having to test this thoroughly
will delay a release even more.
Let's focus on a release first!

Met vriendelijke groet,

Alexander Broekhuis

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message