Monty Taylor wrote:
> Yes. That should be DRIZZLE *...
> Ok. I think I have officially drug this branch down the rathole. I'm
> terribly sorry for wrecking work and delaying DBD::drizzle...
Don't apologize, there is no need to. :)
> Jay just sent me an email about his work in the tree today, which came
> to the sensible conclusion that the changes I was committing were too
> interwoven to be able to backtrack through them successfully... and he's
> totally right.
>
> Jay is going to look at starting from scratch from trunk and starting to
> apply the patches one bit at a time. (I think I know where it broke, but
> it's all too much atm)
>
> I think we should/can divvy this up a bit, so we don't (and by we, this
> week I seem to mean me) break each other's work.
>
> SO, I propose these related but unrelated tasks.
Yes, small, bitesize tasks, each attached to a blueprint which can be
made dependent on each other. Create a branch for each small task,
attached to the blueprint. Merge proposals will go from small task
branch -> medium task branch -> large task branch ->trunk. I am happy
to manage the blueprint dependencies and simply assign them to you and
Patrick as you want them...I am also working on putting together a
buildbot master soon so we can start automating builds and tests.
> TASK ONE: Rename mysql to drizzle OR to something more generic where it
> will touch storage engines. This includes:
The above is a medium task, composed of the below small tasks...
> - Replacing use of the MYSQL_TYPE_* constants to FIELD_*
> - Renaming MYSQL_* types in drizzle.h to DRIZZLE_*
> - Renaming MYSQL* defines to DRIZZLE*
> - Changing mysql_init() to drizzle_create()
Cool. :)
> - Moving my_thread_init(), my_net_init(), etc. into drizzle_create()
Excellent.
> - Rename mysql_real_* to just drizzle_*
Or killing them off completely. If it smells like a hack, it probably is...
> (I think I can re-do the first four bullets above pretty quickly now
> that I know where it's all hanging together. I'd like someone else to
> look at bullet 5 - I think it needs a different set of eyes.)
Happy to.
> TASK TWO: Remove the mysys/mystrings depends from libdrizzle. The main
> depends are charsets, my_malloc/my_free, some lame string manipulation
> functions (and one nice one), bad header file organization and errors.
> (Could conceivably be done in parallel... but probably should wait for
> the above to be done and merged)
Again, this is a medium task with the following smaller tasks. What
should be decided is whether indeed this can be done in parallel or this
is dependent on the above tasks being completed. I suspect that they
can be done in parallel but in separate, smaller trees.
> - Replacing my_malloc/my_free with normal malloc/free
Sure, but some places should not be a blanket replacement. I noticed a
couple places in your tree where my_multi_malloc() was replaced with
many small malloc calls, which is not efficient...perhaps for now tackle
single malloc calls. IMHO, For this tree, it is essential that valgrind
be run cleanly before any merge into another tree...
> - Removing use of non-standard string functions
> - Removing charset references from libdrizzle (make the lib send the
> bytes the programmer sends)
Heh, these two might have to wait a bit...
> - Moving some stuff around in headers (I think I did this mostly
> right, so most of this can be copied verbatim)
> - Removing use of MEM_ROOT in libdrizzle. This most affects
> MYSQL_FIELD and MYSQL_ROWS. While we're at it, we curse the
> MYSQL_ROWS implementation. (BTW Stewart - the first time I did
> this, I was yearning for talloc...)
This is a medium task in itself in my opinion, even if only for
libdrizzle. Messing with MEM_ROOT is a serious undertaking. I would
recommend moving this to a separate medium task and branch.
> TASK THREE: Figuring out what to do with the ER() macros and
> client_errors[] (NOT RELATED TO THE ABOVE... CAN BE PARALLEL)
> (I didn't do this right the first time at all)
> This whole thing is a mess, as there are global static arrays that are
> shared between client and server, and we generate these things with
> comp_err. I'd say it's a later design issue to be solved, but it's
> keeping libdrizzle tied to mysys... and it's a spiderweb anyway.
This task should be dependent on both medium task 1 and 2 (b/c of
changes to the same files in #1 and movement of header files in #2)
> Once all of that is done and all still compiles and is merged, _then_ we
> can tackle (instead of doing it all in one fell swoop):
>
> - Removing references to deprecated things in client/
>
> - Password support functions
> - Unix Domain Sockets
> - Shared Memory
> - Embedded Server
> (but keeping the command line options as null-ops for now)
Yep, medium task with subtasks all dependent on #1,2,3.
> - Removing mysys/mystrings from client/
This is going to be a larger debate. ;)
> - moving mysqlbinlog to a binlog dir, which will eventually also house
> binlong related files from server/ for a libbinlog ... but that's a
> whole other thing.
Sure.
> Hopefully if we do it right, dormando and krow can continue working on
> the blocking/non-blocking IO issue, and possibly krow's interest in
> removing vio...
Sure.
> At this point, libdrizzle can become a source package with no external
> depends. and we can:
>
> - Rearrange/split up header files and code for libdrizzle - sort of like
> how libmemcached is - file for DRIZZLE_ROW, file for DRIZZLE_FIELD, etc.
Yep, this is the last major task...
> Thoughts/comments? Bricks to the head? If this sounds good to you guys,
> I'll transfer it to the blueprint...
Happy to help. Shall we get going? :)
-jay
> Monty
>
> Patrick Galbraith wrote:
>> Monty,
>>
>> Now I get this error:
>>
>> o -MD -MP -MF ".deps/linktest.Tpo" -c -o linktest.o linktest.c; \
>> then mv -f ".deps/linktest.Tpo" ".deps/linktest.Po"; else rm -f
>> ".deps/linktest.Tpo"; exit 1; fi
>> linktest.c:2:25: error: mysql/mysql.h: No such file or directory
>> linktest.c: In function ‘main’:
>> linktest.c:13: error: ‘MYSQL’ undeclared (first use in this function)
>> linktest.c:13: error: (Each undeclared identifier is reported only once
>> linktest.c:13: error: for each function it appears in.)
>> linktest.c:13: error: expected ‘;’ before ‘my’
>> linktest.c:15: error: ‘my’ undeclared (first use in this function)
>> make[1]: *** [linktest.o] Error 1
>>
>> So, linktest.c has:
>>
>> nt main(int argc, char** argv) {
>>
>> (void)argc;
>> (void)argv;
>>
>> MYSQL my;
>>
>> ...
>>
>> Shouldn't it be DRIZZLE my ?
>>
>> Monty Taylor wrote:
>>> Patrick Galbraith wrote:
>>>
>>>> Monty Taylor wrote:
>>>>
>>>>> I stuck a file called "linktest.c" into the libdrizzle dir to test for
>>>>> missing symbols in libdrizzle while we were removing depends. Sounds
>>>>> like it got removed.
>>>>>
>>>>> Patrick Galbraith wrote:
>>>>>
>>>>>> I have all the client calls renamed to drizzle_xxx and when
>>>>>> compiling, get this error that doesn't tell me much:
>>>>>>
>>>>>> creating libdrizzle.la
>>>>>> (cd .libs && rm -f libdrizzle.la && ln -s ../libdrizzle.la
>>>>>> libdrizzle.la)
>>>>>> make[1]: *** No rule to make target `linktest.o', needed by
>>>>>> `linktest'. Stop.
>>>>>>
>>>>>> That's the only error, everything else seems to go fine. Any
>>>>>> thoughts? I could push this to a special tree if anyone wants to look
>>>>>> at it.
>>>>>>
>>>>>> --Patrick
>>>>>>
>>>>>>
>>>> Monty,
>>>>
>>>> Could you please re-commit/push ? ;)
>>>>
>>> Yes! Committing-pushing right now!
>>>
>>> Monty
>>>
>>
>
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
