Assume I have /foo/X.a and /foo/X.dylib, and LDFLAGS=-L/foo. What will AC_CHECK_LIB do? Is .dylib guaranteed to take precedence over .a? Vice versa? Random?
Assume I have /foo/Y.a and /bar/Y.a, and LDFLAGS=-L/foo:/bar? What will happen then?
Is there some way to manually establish precedence?
This problem is not addressed by autoconf. In the case that you have both /foo/X.a and /foo/X.dylib, the configure script will simply attempt to link with libX and will do whatever your toolchain does. If your linker uses X.a, then the configure script will do its tests using X.a. If your linker uses X.dylib, then the configure script will use that. The way to establish precedence will therefore depend on your toolchain (e.g. perhaps you can add -Bstatic to LDFLAGS).
Is there some way to manually establish precedence?
You are manually establishing precedence of library search by using the -L option.
Also what if I have /foo/Y.a and /bar/Y.a, and LDFLAGS=-L/foo:/bar
What will happen then?
It will look in the directory /foo:/bar before the default library paths. It's not clear from your question if Y.a is actually supposed to be linked to anything.
What will AC_CHECK_LIB do? Is .dylib guaranteed to take precedence over .a? Vice versa? Random?
It won't be random, but will be influenced by other options given to configure (e.g. LDFLAGS, --disable-shared, etc.). All AC_CHECK_LIB does is plop in the name of the selected function into a main function (with appropriate libraries added) and see if it links.
Related
I am working on a configuration program - it isn't autoconf, but I'm trying (as much as possible) to get it so that ./configure files that use it can be interfaced in a similar manner to those that are made with autoconf -- and that means (as much as possible) supporting the same variable options.
Only there's one option that makes no sense to me. I mean, yes, I am fully clear on what the option means, I just can't conceive of a single scenario in which someone would be well-advised to use that option - except for one scenario in which I'm equally curious why ./configure scripts can't auto-detect the information it would provide.
The option I am referring to is the "--srcdir" option. The reason it so befuddles me is that the only scenario I can imagine in which the source-code files won't be in your present-working-directory (or relative to your present-working-directory as the configure script is programmed to expect) is if the "configure" script itself isn't in your present-working-directory ---- and in that one scenario, I really am unable to imagine why the "configure" script can't extrapolate the source-directory from the name it is invoked by - and instead has to have that --srcdir option to give it that information.
For example, let's say your program's source-code is located in the "awesome/software" directory. That means that, from where you are, the "configure" script would be "awesome/software/configure". Why can't the "configure" script deduce that the source-directory is "awesome/software" just from the fact that it is invoked by the name "awesome/software/configure", and instead require me to add a separate command-line option of: --srcdir=awesome/software
And if this is not the kind of scenario where one would need to specify the --srcdir option (or if it is not the only kind of such scenario) can someone describe to me any other kind of scenario where the person installing a program would be well-advised to alter the "srcdir" variable from it's default?
The option I am referring to is the "--srcdir" option. ...
the only scenario I can imagine in which the source-code files won't be in your present-working-directory (or relative to your present-working-directory as the configure script is programmed to expect) is if the "configure" script itself isn't in your present-working-directory
Right.
and in that one scenario, I really am unable to imagine why the "configure" script can't extrapolate the source-directory from the name it is invoked by - and instead has to have that --srcdir option to give it that information.
I'm not sure it's required. The configure script will attempt to guess the location of srcdir:
# Find the source files, if location was not specified.
if test -z "$srcdir"; then
ac_srcdir_defaulted=yes
# Try the directory containing this script, then the parent directory.
...
So if it's in neither of those places, this will fail, hence the need for --srcdir. Maybe this is (was?) needed where there's some kind of performance differential where the sources are stored on a "slow" drive and the build happens on a "fast" drive, and configure seems to run faster on the "fast" drive so it needs to be there as well...
At any rate, --srcdir is just a variable assignment, so it's not hard to do.
Why can't the "configure" script deduce that the source-directory is "awesome/software" just from the fact that it is invoked by the name "awesome/software/configure"
The configure source seems to do that without specifying --srcdir, but I have not tried it.
I have defined list_t in my project that got list module API like list_pop(). But now I have to use MySQL lib to communicate with DB, but the MySQL lib still got its list implements, and also defined a list_pop() API. In my other modules, I have to link both of them, and comes the conflict.
One of my solution is, separately include header file for different list API calling, this works well, but while some function need to call both of MySQL::list_pop() and local::list_pop(), how to notify the compiler the correct link point? Is there some GCC trick that can do these without any changes to local::list_pop()?
For most practical purposes, you are going to have to rename one or the other set of functions. It is probably easier to rename your own than those of MySQL.
The simplest approach is to simply add a prefix that has a higher probability of being unique (enough), such as your initials, or the codename of your project, or something. Or you can rename everything to avoid collisions, being aware that MySQL might add a new function in the future.
This is exactly why namespaces were invented for C++, and why C projects usually have systematic prefixes on sets of functions.
There is a way to solve this. Refactor your list_pop() to, say, my_list_pop().
There is one other way to solve this,
Looking at the header of the MySQL my_list.h here, https://github.com/lgsonic/mysql-trigger/blob/master/mysql/my_list.h you can see that list_pop is just a macro, and its binded at compile time, not at runtime(hence not a real library function). Changing list_pop of MySQL to list_pop_my(just in the #define) can make it do what you want it to do.
Is there a way to use the maven-processor-plugin (or any other plug-in) to execute annotation processors listing the ones to skip? I have little control on the processors my dependencies might use but I do know the one I want skipped.
The only option in the usage page is to list the ones you want to include but not the other way around.
Is there a way to do this in Maven?
This is not a question of the maven plugin, but of the availability of javac options. According to the javac reference on annotation processing
Processors are located by means of service provider-configuration files named META-INF/services/javax.annotation.processing.Processor on the search path. Such files should contain the names of any annotation processors to be used, listed one per line. Alternatively, processors can be specified explicitly, using the -processor option.
So for now there's no way to remove an annotation processor, just whitelist the ones you want to run.
I am not seeing mysql as one module when i do php -m. I visited various other questions and checked php.ini but I don't see this line extension=php_mysql.dll
Do i need to add this line? if yes, where it should go. please clarify.
Yes, unless MySQL's module is compiled directly into PHP (in which case it'd be always available), you have to explicitly state you want the external .dll loaded.
As for where it should go, it depends. PHP has usually has at least 2 main .ini files, one for webserver-embedded operations, and one for command line operations. You'll have to add the line to whichever is applicable for your case. It doesn't hurt to add it to both, unless you want a "stripped down" PHP with as few modules loaded as possible.
I've read many times and agree with avoiding the use of globals to keep code orthogonal. Does the use of the config file to keep read only information that your program uses similar to using Globals?
If you're using config files in place of globals, then yes, they are similar.
Config files should only be used in cases where the end-user (presumably a computer-savvy user, like a developer) needs to declare settings for an application or piece of code, while keeping their hands out of the code itself.
My first reaction would be that it is not the same. I think the problem with globals is the read+write scenario. Config-files are readonly (at least in terms of execution).
In the same way constants are not considered bad programming behaviour. Config-files, at least in the way I use them, are just easy-changable constants.
Well, since a config file and a global variable can both have the effect of propagating changes throughout a system - they are roughly similar.
But... in the case of a configuration file that change is usually going to take place in a single, highly-visible (to the developer) location, and global variables can affect change in very sneaky and hard to track down ways -- so in this way the two concepts are not similar.
Having a configuration file ususally helps with DRY concepts, and it shouldn't hurt the orthogonality of the system, either.
Bonus points for using the $25 word 'orthogonal'. I had to look that one up in Wikipedia to find out the non-Euclidean definition.
Configuration files are really meant to be easily editable by the end user as a way of telling the program how to run.
A more specialized form of configuration files, user preferences, are used to remember things between program executions.
Global is related to a unique instance for an object which will never change, whereas config file is used as container for reference values, for objects within the application that can change.
One "global" object will never change during runtime, the other object is initialized through config file, but can change later on.
Actually, those objects not only can change during the lifetime of the application, they can also monitor the config file in order to realize "hot-change" (modification of their value without stopping/restarting the application), if that config file is modified.
They are absolutely not the same or replacements for eachother. A config file, or object can be used non-globally, ie passed explicitly.
You can of course have a global variable that refers to a config object, and that would be defeating the purpose.