Hello,
Mateusz Loskot wrote:
> Yes, this is a well known issue and I'm having a pain in my arse with
> finding how to solve it. The problem is that core name clashes with core
> directory and core dump file potentially existing in source root.
> autotools actions do clean core dump files, so they try to do
> "rm -f core" which in fact tries to remove SOCI core subdirectory
> from filesystem and this, obviously, fails.
>
> Simple solution would be to...rename SOCI's core directory.
>
> Maciej, I'm a kind of lost with how to solve this annoying issue.
> Number of people have asked for solution.
> Would it be renaming possible?
It is all a matter of point of view.
There is obviously a clash between SOCI and autotools, the question is
only where we should look for the solution.
As far as I'm concerned, the problem is in the autotools. They should
not assume anything (after all, autotools are expected to *check* the
local environment, right?) about our file naming conventions. Any
assumption can be made only if there is a way to override the default
with some configuration parameter. If this functionality is not present
in autotools, then we should send it to them as a feature request. Or
rather as a *bug report*.
An important aspect here is also the focus. Autotools is not central to
SOCI. It is merely a boundary utility that is perhaps convenient for
users and not even for all of them (hint: Windows users don't care, but
we would have to modify all Windows scripts as well). Changing anything
in the project to be "compliant" with some boundary utility is a
design/implementation distortion for me. I really mean it.
If we find that it is not possible to use autotools without the
directory name change, and that autotools is so useful that not having
it could introduce the risk of rejecting the whole library by some group
of users, then of course changing the directory name will be the way to
go ("soci-core", perhaps?). But before we declare that it is necessary,
I would like to note that we do not hit this problem regularly. I mean -
the problem is known, but it does not pop up every time the new user
tries to compile the library - it appears not to be a *systematic*
problem. This means that there is some specific way of use or some
specific condition that triggers this problem and that the majority of
users happens to go through the compilation process without ever hitting it.
How is that possible? What particular use case make this problem come
up? When does autotools try to rm -f core and when it does not?
Regards,
--
Maciej Sobczak * www.msobczak.com * www.inspirel.com
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Soci-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/soci-users
