celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pepijn Noltes <pepijnnol...@gmail.com>
Subject Re: Celix 0.0.1 release and Native-OSGI
Date Tue, 21 Aug 2012 20:24:45 GMT
On Tue, Aug 7, 2012 at 11:27 AM, Alexander Broekhuis
<a.broekhuis@gmail.com> wrote:
> Hi,
>> 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.

True, but CMake generates a makefile with a install target. I prefer
that this install target works as expected.

>> 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.

Agreed, although I do think it is important to have a easy to
understand and working build and install target for a first release,
it is a big change and we should not delay a first release any more
that really necessary.

We can pick up the discussion after the first release ;)

> 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
> bundling/installation.
> 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!


View raw message