On Tue, Aug 7, 2012 at 11:27 AM, Alexander Broekhuis <[email protected]> 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
