[
https://issues.apache.org/jira/browse/MINIFICPP-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16994540#comment-16994540
]
Arpad Boda commented on MINIFICPP-1100:
---------------------------------------
The size of the build isn't moot, we can go below 16 MB, our current Win
executable is around 8MB, so I would prefer to avoid boost as much as I can.
It's fine to have some extensions that depends on boost (for a given
functionality you pay the price in build time and binary size), but I think
core should definitely be boostless.
Core doesn't include any big libs, so even though it's static linked, it's
still pretty smart.
Moreover core atm doesn't require boost. There are core codes that can utilize
boost (such as fileutils), but doesn't require boost to be present, it can
fallback to other implementation. Given this background, this ticket
deffinitely cannot be 0.7.0 as that would introduce boost as a new mandatory
dependency.
If you would like to add boost base64 functionality as an option and you can
select between our own impl and boost using compiler flags, I'm totally happy
with that. Just make sure it's not default.
> Replace custom base 64 encoding with Boost or alternative.
> -----------------------------------------------------------
>
> Key: MINIFICPP-1100
> URL: https://issues.apache.org/jira/browse/MINIFICPP-1100
> Project: Apache NiFi MiNiFi C++
> Issue Type: Bug
> Reporter: Marc Parisi
> Priority: Blocker
> Fix For: 0.7.0
>
>
> Per the discussion of MINIFICPP-1026, I think using and referencing boost lib
> for not only this component but also others is ideal.
> "Yep. I was 1. My gut suggestion was to use boost's base 64 since it's
> relatively isolated. If you look at the boost variant they mention portions
> come from this repo ( [https://github.com/ReneNyffenegger/cpp-base64])"
>
> Since we have increased the build with static libs we might as well begin
> explore simply using boost directly. The size of the build is moot at that
> point. We should have rationale why custom libs are added to our core when
> alternatives exist that are more widely used.
> Build time, if we only reference portions of boost, should not increase
> dramatically.
>
> I believe that this should occur despite the inertia of the expedient merge
> and should function as a augmentation of the tests and replacement of the
> custom code in StringUtils.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
