HAE / Core Team,
I'm on the team planning the 16.10 Common Device Models project, and
I'd like to raise one issue with the proposal to postpone removal of
the use of Core private headers until after the 16.04 release.
Specifically, the use of [qcc/SmartPointer.h] in
[inc/alljoyn/hae/DeviceInfo.h] concerns me.
DeviceInfo.h is in the pubic HAE interface and defines a DeviceInfoPtr
type used in the DeviceListener public interface. Given this is the
public interface, would we need to deprecate the use over several
release versions? If so, the issue of removing private Core headers
couldn't be resolved for the 16.10 release. As long as the use of
SmartPointer exists (deprecated or not) we'd need to continue
including its header.
I see the current options as:
1. Replace the use of SmartPointer in DeviceInfo.h with std::shared_ptr
2. Leave as is in 16.04, deprecate in 16.10
3. Leave as is in 16.04, remove in 16.10
I'd prefer option #1. HAE already uses <map>, <vector> and <utility>
headers in its public interface, and I doubt they can be removed
pre-16.04. Adding <memory> seems like the least evil solution.
Option #2 means the SmartPointer.h dependency sticks around for a few
versions. Option #3 is just not very nice, but it is the easiest.
I'm less concerned with use of other private Core headers. They appear
in the private implementation of HAE and can be corrected for the
16.10 release without affecting 16.04 consumers.
Regards,
Brian Hollister
Developer · Two Bulls
On Fri, Jun 24, 2016 at 9:03 AM, Lioy, Marcello <[email protected]> wrote:
> HAE team members,
>
>
>
> Those headers are not included in the distribution because there are not
> public APIs (i.e. they are only meant to be used by Core itself). As I see
> it the HAE has two options:
>
> 1) (same as 1 below) refactor to remove the dependencies on these
> projects
>
> a. I recognize this may be an issue given the current timelines
>
> 2) For the 16.04 release require the source of Core to be included to
> use this release AND plan on removing this dependency either in a 16.04.00a
> release, or a 16.10 release.
>
>
>
> It is not feasible for the Core team to expand our existing API surface.
> Especially in 16.04 as that release has shipped, and even in the 16.10 time
> frame we cannot commit to supporting such an increase in scope.
>
>
>
> From: [email protected]
> [mailto:[email protected]] On Behalf Of
> seungchul.han
> Sent: Tuesday, June 21, 2016 10:34 PM
> To: [email protected]; [email protected]
> Cc: [email protected]
> Subject: [Allseen-core] FW: [Allseen-hae] Building HAE independently of
> AllJoyn source code
>
>
>
> Dear all,
>
>
>
> The HAE project has some problem for building sources codes independently.
>
> Please refer to a mail below about details.
>
>
>
> I think option 2 is better than option 1, because we have to change a lot of
> codes in order to remove all dependencies on qcc lib.
>
> If we choose option 1, it could be a hard task against deadline of first
> release.
>
> So I'd like to ask CoreWG members about this issue.
>
> Could you update common/SConscript like attached patch-set?
>
> If it's possible, which version could be the best candidate version? (The
> HAE project has been developed based on v16.04.)
>
> If not, let us know your opinion about this issue.
>
>
>
> Your help will be greatly appreciated.
>
>
>
> Best Regards,
>
> Seungchul.
>
>
>
> From: [email protected]
> [mailto:[email protected]] On Behalf Of
> [email protected]
> Sent: Thursday, June 16, 2016 10:12 PM
> To: [email protected]
> Subject: [Allseen-hae] Building HAE independently of AllJoyn source code
>
>
>
> Dear all,
>
>
>
> Currently, to build HAE, we need to have the source code of AllJoyn Core as
> well as the source code of AllJoyn HAE. AllJoyn Core should be located
> inside a specific directory (../../alljoyn/core).
>
> It would be nice to remove this dependency as since 16.04 we can build
> AllJoyn base services (onboarding, notification and controlpanel)
> independently of Alljoyn Core through the ALLJOYN_DISTDIR scons variable.
>
>
>
> To break this dependency, I tried to update HAE by adding a build_core
> directory inside the HAE project and updating slightly the SConstruct to
> replace the inclusion of ../../core/alljoyn/build_core/SConscript by
> ./build_core/SConscript (as it was done in AllJoyn Onboarding base service:
> https://git.allseenalliance.org/cgit/services/base.git/tree/onboarding/SConstruct).
>
>
>
> However, when compiling HAE using ALLJOYN_DISTDIR, the compilation fails
> because HAE source code uses some internal headers from AllJoyn Core which
> are not copied into AllJoyn dist directory.
>
> Those files are:
>
> - qcc/SmartPointer.h (used in DeviceInfo.h)
>
> - qcc/StringSource.h (used in cpp/src/HaeAboutData.cc and
> cpp/samples/DeviceEmulator/ConfigLoader.cc)
>
> - qcc/Event.h (used in cpp/unit/unit_test/DUT/HaeTest.h)
>
> - qcc/Util.h (used in most source files)
>
>
>
> This is an issue, as because of this, we’re unable to build HAE without the
> source code of AllJoyn Core which will prevent the “clean” integration of
> HAE into some build systems like buildroot or openwrt.
>
>
>
> So, there is two options,
>
> - Remove the dependencies on those files from HAE source code
>
> - Update common/SConscript from AllJoyn Core to install the files used
> by HAE in qcc dist directory however this will draw a lot of dependencies
> (see attached file), for example:
>
> - qcc/Event.h depends on qcc/posix/Event.h
>
> - qcc/StringSource.h depends on qcc/Stream.h which depends on qcc/Socket.h …
>
>
>
> What do you think of this issue perhaps you should seek advice from the TSC?
>
>
>
> Best Regards,
>
>
>
> Fabrice
>
> _________________________________________________________________________________________________________________________
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
>
> Thank you.
>
>
> _______________________________________________
> Allseen-core mailing list
> [email protected]
> https://lists.allseenalliance.org/mailman/listinfo/allseen-core
>
_______________________________________________
Allseen-core mailing list
[email protected]
https://lists.allseenalliance.org/mailman/listinfo/allseen-core
