Opened 9 years ago

Closed 8 years ago

#76 closed defect (fixed)

several public headers mess with user's projects

Reported by: bubla Owned by: andreasw
Priority: major Component: configuration tests
Version: 0.5 Keywords:
Cc:

Description

Hello, I have discovered that your public headers contain stuff that should be internal. For example OsiConfig?.h #undefs PACKAGE_NAME I think that this issue is closely related to the build system, so I post it here. It took me half an hour to figure out why I can't use PACKAGE_NAME in my program because of this :-)

I wonder what's the reason for it anyway. For instance if this is needed during build time, it should be placed into a protective #ifdef section that is accessible only during build... An article that says something about this can be found here: http://www.linux.com/archive/feature/114061

Change History (5)

comment:1 Changed 9 years ago by stefan

The reason for the #undef's is that each COIN-OR project has it's own config_xxx.h file, but a higher level project may need to read the configuration of the lower level project by including it's config_xxx.h file. Thus, there are wrappers XXXConfig.h which include the actual config_xxx.h and undefine macros that are common among different config_xxx.h files (and they define some macros to default values in case one builds without autotools).

Unfortunately, it does not always seem possible to avoid that a public header of a project includes its config_xxx.h file (well, at least in my case it may be lazyness ;-)). The easy workaround is to include the XXXConfig.h file before your config_xxx.h file, if possible.

I do not see a possible fix for all projects. If you think that a particular project (e.g., Osi), could make it's inclusions of XXXConfig.h private, then I suggest to submit a ticket there, preferably with a patch file included :-).

Anyway, thanks for pointing this out. I leave the ticket open since it is surely something to work on.

Stefan

comment:2 Changed 9 years ago by tkr

I think the submitter makes a valid point. The point is that the config_xxx.h files should not be _installed_, which is separate from the mechanism we use internally to eliminate conflicts during the build process. Actually, there are tons of headers installed that should not be---most projects just install every header without considering which ones are really necessary. A while back, I tried to launch a campaign to fix this, but it largely failed :(. SYMPHONY installs just one header, which contains the API and that's it. I believe this is how it should be with most projects. We should look into this a little more carefully.

Ted

comment:3 Changed 9 years ago by bubla

I think that a fix it should be relatively easy. I am going to investigate more and I will write here or to the mailing list if I have some findings / questions.

Regards, Matěj

comment:4 Changed 8 years ago by stefan

We have started to change things.

It's documented here.

comment:5 Changed 8 years ago by stefan

  • Resolution set to fixed
  • Status changed from new to closed

Done for all projects currently in CoinAll/trunk. Will merge into stables and releases from here.

Note: See TracTickets for help on using tickets.