Re: Celix 0.0.1 release and Native-OSGI

[Alexander Broekhuis <a....@gmail.com>]

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.


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


-- 
Met vriendelijke groet,

Alexander Broekhuis

Re: Celix 0.0.1 release and Native-OSGI

[Pepijn Noltes <pe...@gmail.com>]

On Tue, Aug 7, 2012 at 11:27 AM, Alexander Broekhuis
<a....@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!
>

Greetings,
Pepijn