Hi Szymon,
On Tue, Nov 13, 2012 at 8:57 AM, Szymon Janc <szymon.janc@xxxxxxxxx> wrote:
>> I agree it is not the best solution. Actually, I think we can overcome
>> the problem completely by getting rid of symlinks for "drivers" (like
>> sap-{u8500,dummy}.c, suspend-dummy.c,
>> telephony-{dummy,maemo5,maemo6,ofono}.c) and having everything
>> built-in and enabled/disabled based on which D-Bus services are
>> running on the system (or, if not possible, by using config options).
>> This would also help with spotting build breakages, since all BlueZ
>> code could be compiled by a single "./bootstrap-configure && make"
>> call.
>
> All code is compiled, it is just not linked.
Sorry, I meant "linked" instead of "compiled" on my explanation. See
the original thread where this was first brought up:
http://thread.gmane.org/gmane.linux.bluez.kernel/30175/focus=30190
It is easier for testing code if it can be enabled/disabled at
runtime, instead of rebuilding with different configure options.
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
