nikhilgupta10
commented
7 years ago nikhilgupta10 imported these comments from Sourceforge: "dchassin":The 'core' thing is a very unfortunate of GLD 1.0 (which was windows only). But I would be very cautious about changing the name of any modules, especially the core. The warning is benign anyway.
,
"jcfuller":- Description has changed:
Diff:
- Milestone: Version 3.0 Stable --> Version 3.2 RC1
- Resolution: --> none
- Component: Build --> none
-
Priority: minor --> major ,
"dchassin":- status: new --> accepted
- assigned_to: Nathan Tenney --> David P. Chassin
-
Component: none --> core ,
"dchassin":The only thing left to do on this ticket is fixing the name of the core folder.,
"dchassin":- Milestone: Version 3.2 RC1 --> Knothole Interim ,
"dchassin":Ticket 964 will address the core rename issue. The rest of these issues seem to have been addressed during the mingw fix. If confirmed, recommend we close this.,
"dchassin":- status: accepted --> assigned
- assigned_to: David P. Chassin --> Jeff
- Resolution: none --> validate ,
Reported by jeffdaily:
Running into some strangeness with the /u201cinstall/u201d target of GLD trunk not actually installing to where I told it to during configure.
Not to mention that the configure script tries to /u201crm core/u201d but core is obviously a directory/u2026
The configure behavior can/u2019t be changed in that case (core files may result from failed compilations or runs of tests). Yeah, I don/u2019t suppose GLD will ever rename that directory to something other than /u201ccore/u201d, right? /u201cgldcore/u201d?
But I/u2019m thinking of creating an /u2018enhancement/u2019 branch for fixing up the autotools build. It/u2019s not in a terrible state, but there are some changes which would be very handy e.g. VPATH builds, non-recursive makefiles.
,